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PREFACE 


This  document  represents  the  final  technical  report  developed  under  Contract 
Number  Nonr-4958(00)  (NAVCOSSACT  Project  Number  90A012,  Study  of 
Programming  Documentation  Standards  and  Specifications).  The  basic 
document  presents  the  research  program  implemented  by  ITT  DISD  in 
developing  the  NAVCOSSACT  programming  documentation  standards  and 
specifications  which  are  provided  in  the  Appendix. 


/ 
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1.0  Introduction 

The  objective  of  Project  90A012  was  to  develop  standards  and  specifications 
for  NAVCOSSACT  programming  documentation  that  would  be  generally 
applicable  to  all  NAVCOSSACT  projects.  The  standards  were  to  be  suffi¬ 
ciently  broad,  yet  detailed  enough  to  be  applicable  to  programming  docu¬ 
mentation  requirements  of  any  NAVCOSSACT  software  system.  The 
specifications  for  the  various  kinds  of  programming  documents  were  to  be 
derived  from,  and  were  to  reference,  the  documentation  standards,  thereby 
enabling  a  consistency  of  documentation  throughout  all  NAVCOSSACT  projects. 
A  hierarchy  of  documentation  was  to  be  established  that  would  provide  a 
logical  relationship  among  documents  and  would  permit  sufficient  flexibility 
for  appropriately  covering  all  types  of  software  systems. 

The  technical  activity  for  accomplishing  the  stated  objective  was  divided 
into  four  basic  parts  as  follows: 

Part  1  -  Determine  NAVCOSSACT's  scope  of  activities  and  programming 
documentation  requirements  through  the  evaluation  of  the  current 
documentation  techniques.  The  evaluation  was  to  include  the 
review  of  NAVCOSSACT  and  related  Navy  directives  and  instruc- 
tions  covering  programming  documentation  and  the  interviewing 
of  appropriate  NAVCOSSACT  personnel  concerning  the  applica¬ 
tion  of  current  procedures  as  well  as  recommendations  for 
improvement. 

Part  2  -  Determine  programming  documentation  techniques  of  other 

organizations  by  the  collection  and  evaluation  of  existing  non- 
NAVCOSSACT  standards.  Contacts  were  to  be  made  with 
appropriate  DOD,  government,  industrial,  and  standards  agencies. 
These  reviews  were  to  assure  utilization  of  all  current  standards 
and  to  provide  for  necessary  standardization  with  other  agencies. 
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'r>rt  3  -  Develop  documentation  standards  and  specifications  for 

NAVCOSSACT  based  on  the  results  of  the  Part  1  evaluation  and 
the  evaluation  of  existing  documentation  standards  external  to 
NAVCOSSACT. 

art  4  -  Evaluate  the  proposed  standards  and  specifications  through 

scheduled  reviews  by  selected  NAVCOSSACT  personnel.  The 
results  of  this  review  cycle  were  to  be  factored  into  the  final 
publications  as  appropriate. 

0  Part  1  -  Evaluation  of  NAVCOSSACT 's  Current  Documentation 

Techniques 

lis  activity  consisted  of  two  major  tasks: 

1.  Review  of  documentation  covering  the  current  NAVCOSSACT 
requirements  for  programming  documentation. 

2.  Interviews  with  appropriate  NAVCOSSACT  personnel. 

1  Documentation  Review 

the  initial  stages  of  the  project,  the  significant  guiding  documentation 
is  obtained  in  order  to  analyze  NAVCOSSACT's  current  programming 
cumentation  requirements.  The  documents  analyze^  Were  NAVCOSSACT 
jtruction  5230. 1A  (Subject:  Project  Management  Manual);  OPNAV 
jtruction  5230, 1A  (Subject:  Submission  and  Processing  of  Project 
quests  and  the  Prosecution  of  Projects  for  Command  Systems  Support); 
NCPAC  Instruction  5230.3  (Subject:  Policy  and  Guidance  for  Implemen- 
ion  of  CINCPAC  ADP  Program);  and  SDC’s  TM-2314/000/00  (Subject: 
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Planning  Guide  for  Computer  Program  Development).  The  formal  program¬ 
ming  documentation  requirements  currently  in  effect  were  derived  from 
these  documents.  A  generalized  documentation  system  was  developed  and 
the  requirements  specified  by  each  NAVCOSSACT  document  were  compared 
against  each  other  and  against  the  generalized  documentation  system  to 
determine  variations  among  the  basic  documents.  The  contents,  purpose, 
and  scope  of  each  currently  required  document  were  analyzed  to  determine 
coverage  of  the  present  documentation  system.  In  addition,  numerous 
sataiples  of  past  and  current  documentation  were  reviewed  to  evaluate 
documentation  practices  within  the  framework  of  the  present  system. 

2 . 2  NAVCOSSACT  Project  Personnel  Interviews 

Throughout  Part  1,  meetings  and  telephone  discussions  were  held  with  the 
responsible  NAVCOSSACT  Project  Leader  and  other  assigned  project 
personnel  to  obtain  required  information  such  as  organizational  relation¬ 
ships  within  NAVCOSSACT,  between  NAVCOSSACT  and  Users,  and  between 
NAVCOSSACT  and  other  Navy  Department  Organizations;  clarification  of 
information  in  the  basic  documents;  and  background  information  regarding 
project  development  procedures  within  NAVCOSSACT.  The  project  personn* 
also  provided  the  necessary  administrative  support  in  obtaining  the  docu¬ 
mentation  for  review  and  scheduling  interviews  with  appropriate  NAVCOSSA* 
operational  personnel. 

2. 3  NAVCOSSACT  Management  Personnel  Interviews 

Early  in  Part  1,  a  meeting  was  held  with  the  NAVCOSSACT  management 
personnel.  This  meeting  was  primarily  oriented  toward  outlining  the  broad 
scope  of  the  over-all  project  to  establish  the  general  framework  of  the  study 
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2.4  NAVCOSSACT  Operational  Personnel  Interviews 


During  Part  1,  interview  meetings  were  set-up  with  NAVCOSSACT  opera¬ 
tional  personnel  to  critique  the  current  NAVCOSSACT  documentation  require¬ 
ments  and  to  obtain  recommendations  for  the  development  of  a  more  effective 
programming  documentation  system.  In  order  to  structure  the  meetings, 
a  detailed  interview  form  was  prepared. 

Personnel  from  the  following  NAVCOSSACT  activities  were  interviewed: 

Data  Processing  Department 
Planning  Systems  Department 
Technical  Command  Systems  Department 
Strategic  Systems  Department 
Support  Systems 
Systems  Integration  Department 

2.  5  Conclusions  from  Part  1  Evaluation 

The  Part  1  evaluation  highlighted  the  need  for  an  up-grading  and  reorienta¬ 
tion  of  the  present  NAVCOSSACT  documentation  system  based  on'the 
expanding  scope  of  NAVCOSSACT 's  project  responsibilities  and  the  increased 
complexity  of  ADP  systems.  The  following  basic  conclusions  were  derived 
from  this  activity: 

a.  The  previously  required  system  documentation  was  inadequate 
for  the  more  complex  systems  for  which  NAVCOSSACT  had  be¬ 
come  responsible.  This  was  particularly  true  where  a  system 
was  composed  of  several  subsystems  each  having  several  pro¬ 
grams.  There  was  no  requirement  for  formal  subsystem 
specifications  or  program  specifications  although  these  were 
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often  produced  informally  as  design  notes.  Therefore,  additional 
intermediate  program  design  documentation  would  have  to  be 
included  in  the  formal  documentation  hierarchy. 


b. 


The  development  of  large  complex  systems  increased  the  scope  of 
previously  required  documents  frequently  causing  them  tu  be 
unwieldy,  untimely,  and  incomplete.  For  example,  the  Preliminary 
Functional  Description  (PFD)  for  a  large  system  could  not  be  pro¬ 
duced  in  the  specified  detail  until  late  in  the  detailed  design  effort, 

* 

often  after  some  programming  could  have  been  started,  making 
the  document  untimely.  In  addition,  the  size  of  such  a  PFD  would 
tend  to  obscure  nr'ch  information  required  by  the  user's  opera¬ 
tional  personnel  such  as  data  base  requirements.  Therefore,  the 
required  documents  would  have  to  be  streamlined  to  permit  effective 
accomplishment  of  their  primary  purposes  and  major  segments 
would  have  to  be  extracted  and  specified  as  separate  documents. 

This  streamlining  was  to  facilitate  timeliness  of  all  documents, 


permit  orientation  of 


each  required  document  toward  its  particular 


readers,  and  expedite  review  and  approval. 

Cv  The  diversity  of  programming  projects  at  NAVCOSSACT  necessitated 
flexibility  within  the  documentation  system  to  assure  sufficient 
documentation  for  necessary  communication  and  yet  preclude  extrane¬ 
ous  material  produced  for  the  sake  of  rigorous  standardization.  For 
example,  a  small  project  does  not  require  all  of  the  formal  documen¬ 
tation  necessary  for  a  large  project;  an  obvious  omission  for  a 
small  project  would  be  a  subsystem  document.  Therefore,  a  standard 
would  have  to  be  developed  to  permit  controlling  th^  scope  of  the 
documentation  system  as  a  function  of  program  size  and  type. 


d.  The  requirement  for  documentation  changes  on  a  large,  complex 
project  necessitated  an  expeditious  change  procedure  that  would 
permit  continuation  of  the  project  development  activity  while 
changes  were  being  processed.  Previously,  the  PFD  was  the  only 
formal  document  in  which  all  system  descriptive  material  was 
retained  with  the  resultant  requirement  for  a  complete  approval 
cycle  for  minor  detail  modifications  in  the  PFD.  Therefore,  a 
change  procedure  standard  would  have  to  be  developed  so  that 
only  major  changes  related  to  basic  system  performance  need  be 
processed  through  a  full  scale  approval  cycle. 

e.  The  increase  in  NAVCOSSACT  projects  and  the  diversity  of 
projects  required  that  the  scope  and  format  of  material  within  a 
document  be  specified  to  a  greater  level  of  detail  in  order  to  in¬ 
sure  comprehensive  presentation  of  material.  In  addition,  the 
larger  population  preparing  and  using  the  documentation  required 
standardization  for  more  effective  use  of  the  system  documents. 
Therefore,  the  required  documents  would  have  to  be  specified  in 
greater  detail  than  previously  required. 

'art  2  -  Evaluatior.  of  External  NAVCOSSACT  Documentation 

.ctivity  involved  the  review  of  documentation  data  solicited  from  appro- 
DOD,  government,  industrial,  and  standards  agenca  .  The  imple- 
tion  of  the  survey  included  trips  to  various  agencies  as  well  as  tele- 
and  correspondence  contacts.  In  addition  to  the  documentation  data 
red  from  other  agencies,  al’  of  the  pertinent  ITT  DISD  projects  were 
ed  for  source  material.  Paragraphs  3.  3  and  3.4  below  provide  lists 
>rence  documents  reviewed  and  agencies  contacted  as  a  part  of  this 
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3. 1  Survey  Plan 


The  Part  2  activity  was  based  on  three  principal  objectives  as  follows: 

1.  Determination  of  government,  DOD,  or  Department  of  Navy 
direction  or  guidance  in  the  preparation  of  project  documentation 
and  in  particular  programming  documentation. 

2.  Determination  of  availability  of  appropriate  documentation  systems 
from  other  agencies  that  could  be  adapted  for  use  by  NAVCOSSACT. 

3.  Accumulation  of  source  material  for  the  development  of  a  pro¬ 
gramming  documentation  system  for  NAVCOSSACT. 

3.2  General  Evaluation 

The  survey  established  that  there  were  no  detailed  directions  or  instructions 
for  the  preparation  of  programming  documentation  per  se.  It  was  determined 
quite  early  in  the  survey  that  no  MIL  Standards  or  Specifications  exist  on  the 
subject;  the  DOD  Standardization  Program  is  intended  to  promote  standardi¬ 
zation  of  items  (equipment,  supplies)  identified  in  the  Federal  Supply  Class¬ 
ification  (FSC)  System  and  does  not  cover  documentation  of  computer  program 
systems.  However,  guidance  for  the  preparation  of  documentation  (i.  e. , 
format,  typography,  production,  etc. )  was  available  and  could  be  utilized  as 
the  basis  for  the  appropriate  standards  in  the  NAVCOSSACT  Documentation 
oystem. 

It  became  evident  as  the  survey  progressed  that  no  one  agency  had  a  complete 
set  of  programming  documentation  standards  and  specifications  comparable 
to  that  planned  for  NAVCOSSACT.  The  survey  results  indicated  that  often 
local  standards  and  guidance  manuals  on  programming  documentation  existed 
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i  government  and  industrial  agencies  and  activities.  In  general,  these 
een  compiled  to  support  the  particular  agencies’  internal  data  processing 
.ties  and  were  not  sufficiently  broad  for  direct  adaptation  to  NAVCOSSACT 
rements.  (Examples  of  these  documents  were  those  received  from  the 
ral  Services  Administration,  Navy  Bureau  of  Ships,  and  Navy  Bureau  of 
ons.) 

the  pertinent  ITT  DISD  projects  were  reviewed  for  source  material  for 
AVCOSS'ACT  Documentation  System.  In  addition,  there  was  a  consider- 
lumber  of  relevant  documents  collected  from  the  survey  of  other  agencies, 
of  the  collected  documents  was  analyzed  and  compared  to  all  the  other 
(d  material  that  had  been  accumulated.  The  desirable  features  of  the 
lent  were  then  extracted  for  inclusion  in  the  system.  In  this  manner,  a 
icant  part  of  the  documentation  system  was  synthesized  from  available 
•ial  which  hacLalready  been  successfully  used. 

Fon-NAV COSS ACT  Reference  Material 

SACCS  Project  465L  Documentation 

ITT  Data  Processing  Center  Documentation 

ADX  System  Documentation 

a.  System  Description 

b.  Operations  Manual 

c.  Program  Flow  Diagrams 

d.  Program  Listings 
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Naval  Tactical  Data  System  (NTDS) 


a.  Annotated  Outline  of  a  System  Design  Specification 

b.  Annotated  Outline  of  a  Program  Design  Specification 

c.  Command  and  Staff  Guide  Manual 

d.  Program  Operations  Manual 

e.  Documentation  Requirements 

f.  Directions  Concerning  Program  Documents 

General  Files 

a.  MIL-STD-218-1  (12/1954)  Technical  Manuals 
Part  1  -  General  Outline  for  Technical  Manuals 

b.  MIL- STD- 218-2  (1/1954)  Technical  Manuals 
Part  2  -  Production  or  Procurement  of  Artwork  for 
Technical  Manuals 

c.  MIL-STD-218-3  (1/1954)  Technical  Manuals 
Part  3  -  Preparation  of  Manuscript  (Final,  Typed)  for 
Technical  Manuals 

d.  MIL-D-5480D  (2/1959)  Data,  Engineering  and  Technical: 
Reproduction  Requirements  for 

e.  Exhibit  RADC-2668  (5/1959)  Specifications,  Military; 
Instructions  for  Preparation  of  (by  Contractors). 

f.  MIL-M-005474C  (TJSAF)  (4/1960)  Technical  Manuals: 

General  Requirements  for  the  Preparation  of 

g.  MIL-S-6644A  (USAF)  (9/1955)  Specifications,  Equipment, 
Contractor-Prepared,  Instructions  for  the  Preparation  of 

h.  AFR5-5  Publications  Policies,  Responsibilities  and  Standards 
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i.  SECNAVINST  P10462.7A  Automatic  Data  Processing 

I 

Equipment  j- 

j.  NAVMAT  4000. 17  Project  Management  Manual 

k.  SECNAV  3870. 1  Use  of  Copyrighted  Material  in  Navy 

Publications 

l.  SECNAV  5600.15  Standards  and  Guidelines  on  the  Distribu¬ 

tion  and  Production  of  Publications  and  Printing 

m.  OPNAVINST  5510.  IB  Security  Manual  for  Classified 

Information 

ni  PRC  Paper  46.40  Information  Flow  Concepts,  Notations, 
f  I1  and  Usages 

o.  Automatic  Data  Processing  Glossary  -  Bureau  of  Budget 


a.  Department  of  Defense  -  OASD  (I  &L)  Office  of  Technical 

0  Data  and  Standardization,  Cameron  Station,  Alexandria,  Va. 

b.  U.  S.  Department  of  Commerce  -  National  Bureau  of 
Standards,  Washington  25,  D.  C. 

c'f  Defense  Documentation  Center  (DDC),  346  Broadway,  New 
York  City,  New  York 

d.  Department  of  the  Navy  -  Bureau  of  Ships,  Washington,  D.  C. 

e.  Department  of  the  Navy  -  Bureau  of  Naval  Weapons, 
Washington,  D.  C. 

f.  Bureau  of  the  Budget  (BOB),  Executive  Office  Building, 
Washington,  D.  C. 

g.  General  Services  Administration  (GSA),  Office  of  Data  and 

Financial  Management  -  Data  Processing  Division,  Washing¬ 
ton,  D.  C.  i 
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h.  Department  of  the  Army  -  Army  Materiel  Command, 

Technical  Data  Office,  Standardization  Branch  (DepSO), 
Washington,  D.  C. 

i.  Department  of  the  Navy,  Chief  of  Naval  Materiel  (DepSO), 
Washington,  D.  C. 

j.  Department  of  the  Air  Force,  Technical  Data  and  Standardi¬ 
zation  Office,  Washington,  D.  C. 

l.  Federal  Aviation  Agency  (FAA),  Data  Processing  Division, 

800  Independence  Avenue  SW,  Washington,  D.  C. 

m.  National  Aeronautics  and  Space  Administration,  Office  of 
Scientific  and  Technical  Information,  Maryland  Avenue  and 
4th Street  NW,  Washington,  D.  C. 

n.  American  Standards  Association  (ASA),  10  East  40th  Street, 
New  York  City  16,  New  York 

o.  Business  Equipment  Manufacturers*  Association  (BEMA), 

234  East  42nd  Street,  New  York  City  17,  New  York 

p.  Electronic  Industries  Association  (EIA),  11  West  42nd  Street, 
New  York  City  36,  New  York 

q.  Association  for  Computing  Machinery  (ACM),  14  East  69th 
Street,  New  York  City  21,  New  York 

r.  American  Federation  of  Information  Processing  Societies 
(AFIPS),  211  East  43rd  Street,  New  York  City  17,  New  York 

s.  Data  Processing  Management  Association  (DPMA),  524  Busse 
Highway,  Park  Ridge,  Illinois 

t.  Society  of  Technical  Writers  and  Publishers  (STWP),  P.O.  Box 
3706,  Beechwold  Station,  Columbus,  Ohio 

u.  American  Documentation  Institute  (ADI),  2000  P  Street  NW, 
Washington,  D.  C. 

v.  American  Management  Association,  Inc. ,  135  West  50th  Street, 
New  York  City,  New  York 
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w.  Western  Reserve  University,  Center  for  Communication  and 

Documentation  Research,  Cleveland  6,  Ohio 

x.  Systems  and  Procedures  Association,  7890  Brookside  Drive, 
Cleveland  38,  Ohio 

y.  U.  S.  Steel  Corporation,  Carnegie  Building,  Pittsburgh,  Pa. 

z.  Secretary-Treasurer  1620  Users  Group,  University  of 
Oklahoma  -  Computer  Lab,  Norman,  Oklahoma 

aa.  IBM  Corporation,  Office  of  Group  Director  of  Standards, 
Armonk,  New  York 

bb.  ThetMITRE  Corporation,  P.O.  Box  208,  Bedford,  Mass, 
cc.  American  Specification  Institute,  134  N.  LaSalle  Street, 
Chicago,  Illinois 

dd.  Standards  Engineers  Society,  170  Livingston  Avenue,  New 
Providence,  New  Jersey 

ee.  National  Office  Management  Association  (NOMA),  Willow 
Grove,  Pa. 

ff.  Department  of  the  Air  Force  -  Systems  and  Logistics  (Dep  So) 
Washington,  D.  C. 


3  5  Conclusions  from  Part  2  Evaluation  j 

The  Part  2  evaluation  established  the  fact  that  current  government  direction 
only  covers  general  documentation  preparation  and  does  not  provide 
guidance  specifically  for  programming  documentation.  It  was  also  deter¬ 
mined  that  no  other  agency  had  a  complete  set  of  programming  documenta¬ 
tion  standards  and  specifications  comparable  to  that  planned  for  NAVCOSSACT. 


The  major  positive  result  from  the  Part  2  activity  was  the  accumulation  of 
standards,  specifications,  and  programming  documentation  which  when 
analyzed  provided  a  substantial  data  bank  for  the  synthesis  of  the  specific 
NAVCOSSACT  documents. 
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4.0  Part  3  -  Development  of  Standards  and  Specifications 

The  development  of  standards  and  specifications  was  essentially  a  two 
step  process  requiring;  first, the  determination  of  an  appropriate  hierarchy 
of  standards  and  specifications  and  second,  development  of  the  detailed 
contents  of  each  standard  and  specification.  In  addition,  the  development 
process  consisted  of  three  distinct  phases:  first,  the  establishment  of 
an  initial  documentation  hierarchy  and  development  of  preliminary  drafts 
based  on  the  results  of  the  Part  1  and  Part  2  evaluations;  second,  the 
evolutionary  modification  of  both  the  hierarchy  and  documentation  contents 
during  the  development  period;  and  third,  the  modifications  to  the  docu¬ 
mentation  system  based  on  NAVCOSS  ACT's  review  of  the  drafts. 

The  Part  1  activity,  Evaluation  of  NAVCOSSACT  *s  Current  Documentation 
Techniques,  was  essentially  completed  prior  to  the  initiation  of  the  develop¬ 
ment  activity.  However  Part  2,  Evaluation  of  External  NAVCOSSACT 
Documentation  Standards,  was  only  partially  complete  because  of  the 
delayed  response  of  many  of  the  contacted  agencies.  Those  responses 
received  subsequent  to  the  initiation  of  the  development  activity  were  used 
to  test  the  preliminary  products  and  new  elements  of  documentation  were 
appropriately  factored  into  the  system. 

4. 1  Development,  of  Documentation  System  Hierarchy 

The  establishment  of  the  documentation  hierarchy  was  the  first  step  in 
the  development  process.  The  initial  hierarchy  was  based  on  the  analysis 
of  the  Part  1  and  Part  2  evaluations  and  was  presented  to  NAVCOSSACT 
for  review  in  the  Part  1  Report,  NAVCOSSACT  Programming  Documenta¬ 
tion  Project.  In  effect,  this  initial  presentation  delineated  the  scope  of 
the  remaining  activities.  It  also  established  the  relationship  of  documenta¬ 
tion  to  the  programming  activity,  the  relationships  among  the  documents 
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themselves,  and  the  relationship  between  the  specifications  and  the 
standards.  Of  primary  importance,  this  initial  presentation  of  a  docu¬ 
mentation  hierarchy  provided  a  basis  for  the  development  of  the  detailed 
elements  of  the  system,  (inference  Figure  1  for  final  hierarchy. ) 

During  the  development  of  the  detailed  standards  and  specifications,  more 
effective  organization  and  categorization  of  material  became  evident  and 
was  implemented  in  the  draft  package  that  was  being  prepared  for 
NAVCOSSACT  review.  This  was  particularly  significant  with  regard  to 
the  standards  resulting  in  a  more  definitive  presentation  of  material. 

4. 2  Development  of  Standards  and  Specifications 

After  establishing  the  documentation  tree,  development  of  the  individual 
elements  (i.  e. ,  standard  or  specification)  was  commenced.  A  principal 
source  for  this  effort  was  the  available  material  from  NAVCOSSACT.  In 
addition,  documentation  data  obtained  in  the  Part  2  survey  provided 
significant  supplementary  information. 

The  standards  were  generally  derived  from  the  NAVCOSSACT  standard 
procedures  and  governing  DOD,  Department  of  Navy,  and  government 
directive  documents  as  well  as  from  material  under  development  by 
industry  standards  agencies  such  as  flow  diagram  symbology.  In  addition 
to  general  documentation  instructions,  NAVCOSSACT  environment  oriented 
programming  documentation  standards  such  as  Documentation  Phasing, 
Document  Review  and  Approval,  and  Project  Documentation  Guideline 
were  developed  based,  to  a  large  degree,  on  the  results  of  the  Part  1 
interviews. 
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The  individual  document  specifications  were  structured  from  the  directive 
material  at  NAVCOSSACT,  the  results  of  the  interviews  with  NAVCOSSACT 
personnel,  and  the  system  documentation  from  completed  NAVCOSSACT 
projects.  The  basic  structures  were  then  enhanced  by  definitive  descrip¬ 
tions  of  required  material  which  was,  in  a  large  part,  derived  from  the 
material  obtained  from  the  Part  2  survey. 

4.3  Conclusions  from  Part  3  Development  Phase 

The  development  phase  was  concluded  by  the  preparation  of  a  complete  set 
of  preliminary  standards  and  specifications  which  were  delivered  to 
NAVCOSSACT  for  review  and  comment.  In  addition  to  providing  a  sub¬ 
stantially  completed  package  from  the  standpoint  of  document  content,  this 
interim  publication  permitted  the  preparation  of  alternative  presentation 
tecljniques  such  as  document  formats  and  the  use  of  charts  and  examples 
for  NAVCOSSACT  evaluation. 

The  development  effort  resulted  in  a  substantiation  of  the  basic  premise 
that  a  set  of  documentation  standards  and  specifications  could  be  provided 
for  the  spectrum  of  program  system  types.  However,  this  activity  did 
highlight  the  problem  of  establishing  criteria  for  evaluating  the  trade-off 
between  specificity  and  general  application;  for  example,  specifying  the 
requirement  for  a  detailed  description  of  an  element  (inputs,  outputs,  etc. ) 
in  a  system  or  subsystem  document  may,  in  some  instances,  affect  the  re¬ 
quired  timing  of  the  document.  It  also  revealed  the  importance  of  the  Part  4, 
NAVCOSSACT  review  to  establish  the  best  level  of  generalization  for 
NAVCOSSACT ’s  over- all  requirements. 

5  0  Part.  4  -  NAVCOSSACT  Evaluation  of  Preliminary  Standards  and 
Specifications 

This  effort  provided  for  NAVCOSSACT  review  of  a  preliminary  documenta¬ 
tion  package.  The  review  served  to  orient  the  standards  and  specifications 
toward  NAVCOSS ACT’s  immediate  needs. 
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The  activity  was  conducted  by  the  NAVCOSSACT  Project  Leader  and  his 
staff.  Elements  of  the  preliminary  documentation  package  were  delivered 
to  the  Project  Leader  as  soon  as  they  became  available  and  copies  were 
then  fanned  out  to  the  various  functional  organizations  within  NAVCOSSACT 
for  review.  The  organizations  Were  requestei  to  rev  ew  the  documents 
for  applicr  tlity  to  their  own  activities;  it  was  noted  that  any  resultant 
inconsistencies  with  a  generalized  documentation  system  would  be  resolved 
in  a  final  coordination  review.  After  all  of  the  preliminary  material  had 
been  reviewed  by  the  individual  organizations,  the  NAVCOSSACT  Project 
Leader  scheduled  a  series  jdf  coordination  meetings  for  review  of  the 
individual  standards  and  specifications.  All  of  the  functional  NAVCOSSACT 
organizations  were  represented  at  these  meetings  insliring  a  universality 
of  view  points.  Each  standard  and  specification  was  reviewed  in  detail; 
consideration  was  given  to  an  element’s  function,  reader  orientation, 
format,  content,  level  of  detail,  and  relationship  to  other  elements  in  the 
documentation  system.  The  results  of  the  NAVCOSSACT  effort  were  then 
returned  to  the  Contractor  for  final  review  and  publication. 

5. 1  Conclusions  from  Part  4  NAV  COSSACT  Evaluation 

l  ,  ’  I 

The  Part  4  evaluation  resulted  in  an  important  focusing  on  NAVCOSSACT’s 
particular  requirements  which  could  only  be  derived  through  intensive 

review  by  the  ultimate  documentation  implementers.  As  a  result  of  this 

;  / 

evaluation,  the  standards  were  modified  to  reflect  the  current  as  well  as 

!  / 

the  anticipated  NAVCOSSACT  environment  and  the  specifications  were 
generalized  by  emphasizing  the  ultimate  responsibility  at  the  Project  Leader 
in  determining  the  documentation  requirements  for  his  project,  hi  effect, 
the  major  consequence  of  the  Part  4  effort  was  a  more  general  orientation 
of  the  documentation  package  v/hich  made  it  universally  adaptable  to  the 
broad  spectrum  of  the  NAYCC3CACT  programming  projects.  Specific 
modifications  resulting  from  the  NAVCOSSACT  evaluation  are  summarized 
below.  ' 
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Documentation  Hierarchy  -  There  were  several  modifications  to  the  pre¬ 
liminary  documentation  hierarchy.  The  Project  Manual  was  originally 
conceived  as  a  distinct  document  retaining  the  functional  material  of  the 
Staff,  the  Operations,  and  the  Program  Maintenance  Manuals,  but  combining 
general  introductory  material  of  the  latter  three  manuals  into  a  single 
introduction.  Based  on  the  review,  the  Project  Manual  will  provide  for 
binding  the  other  three  manuals  into  a  single  volume  with  no  textual  change. 
A  second  modification  to  the  specification  tree  provided  for  combining  the 
Acceptance  Test  Plan  and  Acceptance  Test  Specification  into  a  single  docu¬ 
ment  under  the  title  of  Acceptance  Test  Plan.  In  addition,  there  was  some 
restructuring  of  the  standards  to  provide  a  more  effective  presentation  of 
material  for  NAVCOSSACT’s  particular  requirements. 

Standards  Content  -  Standards  modifications  were  recommended  to  provide 
for  compatibility  with  current  NAVCOSSACT  definitions  and  procedures. 

In  order  to  clarify  the  meanings  of  certain  standards,  it  was  recommended 
that  illustrative  examples  be  included  such  as  formats  for  tables,  illustra¬ 
tions,  and  equations.  Modifications  were  also  recommended  to  maintain 
consistency  with  current  procedures;  e.g. ,  the  Documentation  Security 
Identification  Standard  was  appropriately  changed  for  compatibility  with 
current  security  practices. 

Specifications  Content  -  Modifications  to  certain  specifica'ions  were  rec¬ 
ommended  as  a  result  of  greater  definitization  of  documentation  functions. 
These  changes  included  the  elimination  of  material  in  order  to  insure 
appropriate  documentation  phasing  and  the  transferring  of  material  between 
specifications  in  order  to  facilitate  review  and  approval  cycles.  In  addi¬ 
tion  since  the  content  of  the  specifications  was  sufficiently  universal  in 
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meaning,  many  examples  and  illustrations  in  the  preliminary  documents 
could  be  removed.  Further,  one  specification  was  substantially  modified; 
the  orientation  of  the  Data  Requirements  Document  was  changed  to  provide 
a  more  effective  tie-in  to  the  Data  Element  Library  effort  currently  being 
implemented  at  NAVCOSSACT. 

6.  0  Conclusions 

The  objective  of  the  Project;  namely,  the  development  of  standards  and 
specifications  for  NAVCOSSACT  programming  documentation,  was  success¬ 
fully  achieved.  In  addition  to  providing  a  substantially  more  comprehensive 
documentation  system,  the  integration  of  the  standards  and  specifications 
furnishes  a  basis  for  progressive  extension  of  the  system  by  NAVCOSSACT. 

The  development  technique  consisting  of  a  review  of  current  NAVCOSSACT 
procedures,  a  survey  of  other  organizations,  preparation  of  a  preliminary 
documentation  package,  and  comprehensive  review  by  NAVCOSSACT 
personnel  prior  to  final  publication  insured  delivery  of  a  workable  docu¬ 
mentation  system  tailored  to  NAVCOSSACT's  requirements. 

The  NAVCOSSACT  documentation  system  should  provide  substantial  assist¬ 
ance  to  the  implementer  in  documenting  a  programming  project.  On  the 
other  hand,  the  requirement  for  more  comprehensive  documentation  will 
impose  a  heavier  document  writing  burden  on  him.  Therefore,  the  next 
step  in  the  documentation  development  cycle  should  be  the  design  of  tools 
to  assist  the  systems  implementer  in  production  of  the  required  documenta¬ 
tion.  The  documentation  system  presented  in  the  Appendix  of  this  Report 
implicitly  suggests  the  development  of  automated  techniques  such  as 
computerizing  data  common  to  several  different  system  documents  and 
automating  the  documentation  change  procedure. 
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The  Appendix  to  the  Report  provides  the  Programming  Documentation 
System  developed  for  NAVCOSSACT  under  this  project.  It  consists  of  a 
complete  set  of  programming  documentation  standards  and  specifications. 
The  Inclusion  of  a  definitive  end  product  precludes  the  presentation  of  a 
more  comprehensive  report  since  the  reader  can  easily  recognize  the 
detailed  development  activities  implied  in  the  results. 


20 


REFERENCES 


Project  Generated 

Part  1  Report,  NAVCOSSACT  Programming  Documentation  Project; 
(6/1965),  ITT  DISD 

NAVCOSSACT 

NAVCOSSACT  Instruction  5230. 1 A,  Project  Management  Manual 
(7/1964) 

TM- 23 14/000/00,  Planning  Guide  for  Computer  Program  Develop¬ 
ment;  (5/1965),  SDC 

Information  Flow  Concepts,  Notations,  and  Usages;  (2/1964) 

PRC  Paper  46.40 

The  Wordsmiths  Guide,  Technical  Service  Division;  (6/1964) 
NAVCOSSACT 


Contractor 


SACCS  Project  465L  Documentation 
ITT  Data  Processing  Documentation 
ADX  System  Documentation 

a.  System  Description 

b.  Operations  Manual 

c.  Program  Flow  Diagrams  and  Listings 


Naval  Tactical  Data  Systems  (NTDS) 


a.  Annotated  Outline  of  a  System  Design  Specification 

b.  Annotated  Outline  of  a  Program  Design  Specification 

c.  Command  and  Staff  Guide  Manual  / 

d.  Program  Operations  Manual 

e.  Documentation  Requirements 

f.  Directions  Concerning  Program  Documents 

General 

OPNAV  Instruction  5230. 1A,  Submission  and  Processing  of  Project 
Requests  and  the  Prosecution  of  Projects  for  Command  Systems 
Support  (10/1964) 

CINCPAC  Instruction  5230.3,  Policy  and  Guidance  for  Implementa¬ 
tion  of  CINCPAC  ADP  Program  (4/1965) 

MIL-STD-218-1  (12/1954)  Technical  Manuals 

Fart  1  -  General  Outline  for  Technical  Manuals 

MIL-STD-218-1  (1/1954)  Technical  Manuals 

Part  2  -  Production  or  Procurement  of  Artw"  *  for  Technical 
Manuals 

MIL-STD-218-3  (1/1954)  Technical  Manuals 

Part  3  -  Preparation  of  Manuscript  (Final,  Typed)  for  Technical 
Manuals 

MIL-D-5480D  (2/1959)  Data,  Engineering  and  Technical:  Repro¬ 
duction  Requirements  for 

Exhibit  RADC-2668  (5/1959)  Specifications,  Military:  Instructions 
for  Preparation  of  (by  Contractors) 


22 


MIL-M-005474C  (USAF)  (4/1960)  Technical  Manuals: 

General  Requirements  for  the  Preparation  of 
MIL-S-6644A  (USAF)  (9/1955)  Specifications,  Equipment, 
Contractor-Prepared,  Instructions  for  the  Preparation  of 
AFR5-5  Publications  Policies,  Responsibilities  and  Standards 
SECNAVINST  P10462.7A  Automatic  Data  Processing  Equipment 
NAVMAT  4000. 17  Project  Management  Manual 
SECNAV  3870. 1  Use  of  Copyrighted  Material  in  Navy  Publications 
SECNAV  5600. 15  Standards  and  Guidelines  on  the  Distribution 
and  Production  of  Publications  and  Printing 
OPNAVINST  5510.  IB  Security  Manual  for  Classified  Information 
Automatic  Data  Processing  Glossary  -  Bureau  of  Budget 


23 


APPENDIX 


NAVCOSSACT  PROGRAMMING  DOCUMENTATION 
STANDARDS  AND  SPECIFICATIONS 


NAVCOSSACT 

SUBJECT 

NUMBER 

STANDARDS 

TABLE  OF  CONTENTS 

PAGE 

1 

OF 

2 

title  number 

NAVCOSSACT  DOCUMENTATION  SYSTEM  Introduction 

PROJECT  DOCUMENTATION  GUIDELINE  10-05 

PROJECT  DOCUMENTATION  PHASING  10-10 

DOCUMENTATION  FORMAT  20-05 

DOCUMENTATION  TYPOGRAPHY  20-10 

DOCUMENTATION  PRODUCTION  20-15 

DOCUMENTATION  SECURITY  IDENTIFICATION  20-20 

DELIVERABLE  DOCUMENTS  AND  MATERIALS  20-25 

DOCUMENT  NUMBERING  30-05 

DOCUMENT  REVIEW  AND  APPROVAL  30-10 

DOCUMENT  DISTRIBUTION  30-15 

DOCUMENT  CHANGE  30-20 

PRELIMINARY  FUNCTIONAL  DESCRIPTION  40-05 

SUBSYSTEM  SPECIFICATION  40-10 

DATA  REQUIREMENTS  DOCUMENT  40-15 

PROGRAM  SPECIFICATION  40-20 

DATA  BASE  SPECIFICATION  40-25 

PROJECT  MANUAL  (Compilation  of  other  manuals)  40-30 

STAFF  MANUAL  40-35 

OPERATIONS  MANUAL  40-40 

PROGRAM  MAINTENANCE  MANUAL  40-45  j 

ACCEPTANCE  TEST  PLAN  40-50  1 

ACCEPTANCE  TEST  ANALYSIS  REPORT  40-55 


NAVCOSSACT 

SUBJECT 

NUMBER 

STANDARDS 

TABLE  OF  CONTENTS 

m 

OF 

2 

TITLE  NUMBER 

50-05 
50-10 
50-15 


PROGRAMMING  TERMINOLOGY 
PROGRAMMING  SYMBOLOGY 
PROGRAM  SYSTEM  CHART  TYPES 


SUBJECT 

NAVCOSSACT 
DOCUMENTATION  SYSTEM 

1.  PURPOSE 

The  purpose  of  the  documentation  system  is  to  provide  standardization 
and  guidance  for  the  preparation  of  computer  programming  documentation. 

2.  SCOPE 

The  documentation  system  provides  that  all  system  development  functions 
from  preliminary  design  to  final  test  be  supported  by  appropriate  documen¬ 
tation.  The  documentation  system  outlines  the  content  and  format  of  each 
document  and  provides  selection,  publication,  control,  and  reference 
standards  for  the  documents  to  be  produced  for  each  program  project.  The 
project  complexity  factor  may  be  used  as  a  guide  to  the  number  of  different 
documents  which  will  be  selected  to  support  a  particular  program  project.. 
The  final  choice  of  documents,  however,  is  the  decision  of  the  Project 
Leader,  and  this  choice  should  also  consider  other  factors,  such  as  type  of 
project  (functional,  support),  amount  of  programming,  size  of  project. 

Each  document  described  herein  serves  a  particular  purpose(s),  and  the 
Project  Leader  will  decide  its  necessity  in  the  documentation  for  his  project. 

3.  OBJECTIVES 

a.  To  specify  the  content  of  each  document. 

b.  To  allow  sufficient  flexibility  in  the  number  of  different  documents 
to  be  prepared  for  each  program  project. 

c.  To  specify  document  formats  and  other  editorial  and  typographical 
requirements. 
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DOCUMENTATION  SYSTEM 
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Introduction 
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d.  To  reference  the  established  procedures  for  processing  and 
handling  documentation. 

e.  To  provide  management  control  through  development'  of  standards. 
4.  ORGANIZATION 

10.  Project  Documentation.  Standards  which  establish  the  scope  of 
the  documentation  effort  required  to  support  projects  of  varying 
’  programming  complexity. 

20.  Documentation  Publication.  Standards  which  establish  constraints 

>  on  the  preparation  and  production  of  programming  documentation . 

t 

30.  Documentation  Control.  Standards  which  establish  procedures 

i 

for  the  identification  and  handling  of  programming  documentation. 
40.  Documentation  Specifications.  Standards  which  specify  the  format 
and  content  erf  NAVCOSSACT  programming  documentation. 

‘  50.  Reference  Information.  Standards  which  summarize  information 

*  .  i 

specialized  to  programming  systems  technology. 


Individual  standards  are  identified  in  the  NAVCOSSACT  STANDARDS  tree 
diagram  in  Figure  1. 
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To  establish  a  guideline  for  the  number  of  different  djcuments  to  be  prepared 


to  support  a  particular  NAVCOSSACT  program  project. 


2.  PROJECT  DOCUMENTATION  VARIATIONS 

This  standard  provides  guidance  for  adapting  a  project’s  documentation  to 
project  complexity.  However,  the  Project  Leader  may  use  other  factors 
to  decide  what  documents  he  needs  to  support  his  project;  e.g. ,  type  of 
project  (support  or  functional),  amount  of  programming,  size  of  project. 
For  small  projects  he  may  need  a  minimum  of  documentation,  which  will 
reduce  the  document  preparation  and  production  effort.  For  large  projects, 
complete  documentation  of  all  phases  of  effort  may  be  needed,  which  will 
provide: 


a.  Control  and  coordination  of  concurrent  and  consecutive  program 
design  effort. 

b.  Coordination  of  program  requirements  and  program  operation 
with  user  personnel. 

c.  Record  of  project  for  maintenance  or  reconstruction  of  delivered 
system  if  required. 

d.  Reference  record  for  planning  and  design  of  subsequent  projects. 


3.  DOCUMENTATION  TYPES 

The  specific  types  of  documents  which  may  be  provided  to  support  a  pro¬ 
gramming  project  are  as  follows: 
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Preliminary  Functional  Description 

Data  Requirements  Document 

Subsystem  Specification  (per  subsystem) 

Program  Specification  (per  program) 

Data  Base  Specification 

Project  Manual 

Staff  Manual 

Operations  Manual 

Program  Maintenance  Manual 

Acceptance  Test  Plan 

Acceptance  Test  Analysis  Report 


The  format  and  content  of  each  of  these  document  types  except  for  the  Project 
Manual  is  given  in  STD  40.  The  Project  Manual  is  a  single  volume  presenta¬ 
tion  of  the  other  three  manuals  with  no  textual  variation:  therefore,  a  specific 
specification  is  not  included  for  the  Project  Manual. 

4.  PROJECT  DOCuJmENTATION  GUIDE 

A  guide  to  the  documentation  which  may  be  generated  for  projects  with 
various  complexity  [actors  is  shown  in  Table  1.  The  project  complexity 
factor  is  A,  B,  C,  D,  E  as  defined  in  NAVCOSSACT  Instruction  5230. 1A. 
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1.  PURPOSE 

To  indicate  in  a  representative  manner  the  phasing  for  the  preparation, 
management  review  and  approval  of  NAVCOSSACT  programming  documen- 
tation. 

2.  PHASING  CONSTRAINTS 

The  preparation  of  programming  documentation  must  meet  the  following 
constraints. 

a.  Logical  Document  Sequence.  The  documentation  system  provides 
for  document  preparation  which  reflects  the  activity  at  different 
phases  of  the  development  effort.  Documentation  must  be  phased 
for  production  when  its  source  material  is  logically  anticipated. 

b.  Minimum  Lag  Interval.  Production  of  documentation  should  be 
undertaken  as  soon  as  a  workable  amount  of  source  material  is 

•4 

available.  In  many  instances  this  will  be  some  time  prior  to  the 
availability  of  final  source  documentation.  Under  these  circum¬ 
stances,  document  production  must  be  scheduled  so  that  a  source 
document  is  formally  released  prior  to  the  release  of  a  lower 
order  document. 

c.  Project  Complexity  Factor.  The  project  complexity  factor 

(A,  B,  C,  D,  E)  as  defined  in  NAVCOSSACT  Instruction  5230. 1A 
is  used  herein  to  provide  a  guide. to  the  types  of  documentation 
which  may  be  used  to  support  a  programming  project  (see  STD 
10-05).  Document  preparation  as  a  function  of  project  complexity 
is  therefore  included  in  the  phasing  process. 
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PHASE  INTERVALS 


3 


Time  mterva's  (in  weeks)  are  associated  with  each  phase  of  document 
prrpuJ^Hcn  Tie  intervals  are  to  be  considered  as  representative,  rather 
♦hun  bir.ding,  and  are  seated  as  being  in  one  of  the  following  ranges. 


a  i-2  weeks 

b  2  *4  weeks 

c.  4-6  weeks 

d  6 -15  weeks 

The  ? 6’  e !■  cf  aCth  5*v  in  each  phase  (man-weeks,  man-months)  is  a  fun  tior. 
of  prc.iec'  s'76  :.nd  is  not  included 

4  DOCUMENTATION  PHASING 

The  preparation  cf  programming  documentation  begins  with  the  preparation 
of  ’hr  Pre  iminary  Fvncticna!  Description  and  concludes  with  the  Accept¬ 
ance  Tes*  AnJysis  Report,  Administrative  activities  associated  with 
initiation  and  termination  of  the  project  are  not  considered  in  this  standard. 


The  ever -a  1  document  phasing  associated  with  a  programming  project  is 
shown  in  Figcre  t. 


System 
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1.  PURPOSE 

This  standard  establishes  the  format  requirements  for  NAVCOSSACT 
documentation. 

2.  GENERAL  FORMAT  REQUIREMENTS 

1  ! 

Documentation  is  to  be  structured  from  the  following  parts  ordered  in  the 
sequence  listed. 


a.  Front  Cover 

b.  Special  Notices 

c.  Revision  Sheet 

d.  Abstract 

e.  Title  Page 

f.  'fable  of  Contents 

g.  List  of  Illustrations 

h.  jList  of  Tables 

i.  taist  of  Abbreviations  and  Symbols 

j.  Text  ; 

j 

k.  References 

l.  Bibliography 

m.  Appendices 

j 

n.  Back  Cover 


(Mandatory) 
(As  Required) 
(As  Required) 
(Optional) 
(Mandatory) 
(Mandatory) 
(As  Required) 
(As  Required) 
(Optional) 
(Mandatory) 
(Optional) 
(Optional) 

(As  Required) 
(Mandatory) 
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3.  DETAILED  REQUIREMENTS 

3. 1  Front  Cover.  The  front  cover  will  contain  the  following  information. 

a.  Activity  name  and  seal 

b.  Document  type  (see  STD  10-05) 

c.  Document  description  (title  and  sub-title) 

d.  NAVCOSSACT  document  number  (see  STD  30-05) 

e.  Security  Identification,  as  required  (see  STD  20-20) 

An  example  of  a  layout  of  a  cover  is  shown  in  Figure  1. 

3. 2  Special  Notices.  Special  information  relating  to  the  status  of  a  docu¬ 
ment  and  instructions  for  its  handling. 

3.3  Revision  Sheet.  The  revision  sheet  will  be  a  cumulative  record  of  all 
changes  made  in  the  document  since  original  publication.  The  changes  will 
be  identified  by  document  number,  date,  pages  affected  and  brief  description 
of  change. 

3.4  Abstract.  A  brief  summary  of  presentation  (150-250  words),  prefer¬ 
ably  unclassified,  including  any  special  circumstances,  features,  techniques 
or  other  material  to  provide  orientation  for  the  reader. 
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5  Title  Page.  The  title  page  will  include  the  same  information  and 
format  as  the  cover  page  with  the  addition  of  preparation  credit  by 
organization  or  codes  and  publication  data,  both  centered  directly  beneath 
the  document  description  information. 


3.6  Table  of  Contents.  Document  contentswill  identify  the  iection/para- 
graph  number,  title  or  heading,  and  page  number.  The  contents  will  be 
tabulated  down  to  three  decimal  numbering  positions. 


3. 7  List  of  Illustrations.  The  list  will  account  for  each  numbered 
illustration,  by  figure  number,  title,  and  page  number. 

*•  H 

3. 8  List  of  Tables.  The  list  will  account  for  each  numbered  table  by 
table  number,  title,  and  page  number. 

3. 9  Text.  The  text  will  follow  the  prescribed  content  for  the  type  of 
document  in  preparation.  Refer  to  NAVCOSSACT  STD  40  for  applicable 
format.  In  addition  to  the  narrative,  tables,  diagrams,  and  illustrations 
may  be  employed  to  convey,  clarify,  or  illustrate  the  technical  content. 


3. 10  Appendix.  The  appendices  will  contain  material  which  supports  but 
is  not  essential  to  the  text.  Appendices  will  be  separately  titled  and 
"numbered”  alphabetically.  A  single  appendix  will  be  titled  only. 
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3. 11  References.  A  list  of  references  will  be  provided  if  more  than  five 
titles  are  cited  in  the  text.  Each  reference  will  contain  Title,  Date,  Docu¬ 
ment  Number  and  Classification,  Author  and  Publisher  if  applicable.  The 
titles  of  books,  papers,  reports,  pamphlets  will  be  underlined;  the  titles  of 
articles  within  a  publication  will  be  placed  in  quotation  marks. 

3. 12  Bibliography.  The  bibliography  will  include  the  same  type  of  informa¬ 
tion  as  required  for  references,  arranged  alphabetically  by  author. 

3.13  Back  Cover.  Unprinted,  except  for  security  classification  if  required. 
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l.j  PURPOSE 

This  standard  establishes  typography  conventions. 
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2.  PREPARATION 

Documentation  will  be  prepared  in  final  form  by  typing  onto  appropriate 
master  stock  using  a  standard  type  face  (e.  g. ,  bold  face,  elite).  The 
typing  area  will  be  6  X  9  inches  centered  on  an  8  X  10-1/2  final  sheet  size. 
The  text  will  extend  across  the  entire  page  between  the  margins  (no  text 
columns).  Single  line  or  line  and  a  half  spacing  may  be  used. 

3.  TEXT  DIVISION 

The  text  of  the  document  is  divided  into  sections,  paragraphs,  and  sub- 
paragraphs.  A  decimal  numbering  system  will  be  used,  and  each  numbered 
division  will  be  identified  with  a  subject  title.  Paragraph  numbering  will 
not  exceed  four  decimal  levels.  Revision  of  the  text  organization  will  be 
‘  made,  as  necessary,  to  conform  to  the  four  level  constraint.  This  page 
is  an  example  of  section  and  paragraph  divisions  and  numbering. 


3. 1  Sections.  Sections  are  the  primary  text  divisions  and  will  be  identified 
by  a  fully  capitalized  subject  title.  The  section  number  and  title  may  start 
a  new  page  of  a  document  and  will  be  left  justified  to  the  upper  left  corner 
of  the  typing  page.  A  double  horizontal  space  will  be  provided  between  the 
section  number  and  the  section  title.  A  double  vertical  space  or  space  and 
a  half  will  be  provided  between  the  section  title  line  and  the  first  section 
paragraph. 
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3.2  Paragraphs  and  Subparagraphs.  The  number  and  title  will  be  left 
justified.  Two  horizontal  spaces  will  be  provided  between  the  paragraph 
number  and  the  title.  The  first  letter  of  each  major  word  of  the  title  will 
be  capitalized  and  the  title  itself  immediately  followed  by  a  period.  The 
paragraph  text  will  start  on  the  same  line  as  the  paragraph  title,  separated 
from  the  title  period  by  two  horizontal  spaces.  The  text  will  start  with 
the  first  letter  capitalized.  All  paragraph  text  will  be  left  justified.  A 
double  line  space  will  be  provided  between  individual  paragraphing. 


3.3  Itemization.  Itemization  of  elements  within  a  paragraph  and  subpara¬ 
graph  may  be  used  in  lieu  of  formal  subparagraphing.  Such  itemization  will 
be  restricted  to  brief  statements  or  word  groups  for  which  decimal  numbering 
would  be  awkward.  Items  will  be  identified  by  lower  case  letters  followed 
by  a  period.  The  letters  will  start  six  horizontal  spaces  from  the  left  mar¬ 
gin  of  the  typing  area.  Two  horizontal  spaces  will  be  provided  between  the 
letter  period  and  the  start  of  the  item.  The  first  letter  of  the  item  will  be 
capitalized.  Additional  lines  under  each  element  will  be  aligned  with  the 
start  of  the  first  line.  A  single  line  space  will  b^  used  between  items. 


4.  TABLES 

Tables,  depending  upon  their  size  and  relationship  to  the  text,  may  be 
included  with  the  t  xt  or  typed  on  separate  pages. 


1. 1  Text  Tab'es  A  text  table  has  an  open  format,  appears  wichin  the  text, 
uid  is  completely  identified  by  the  text;  it  has  neither  title  nor  number.  It 
vill  usually  be  a  part  of  the  sentence  that  identifies  it.  An  example  of  a 
ext  table  is  shown  in  Figure  1(a)  on  the  following  page. 
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4. 1  Example.  -  The  C160-A  EXF  codes  for  the  Control  Alarm  are  in 
the  ringe  2270  through  2277.  Any  of  the  EXF  codes  2270  through  2272 
select  the  Control  Alarm;  any  other  code  deselects  it. 


2270 

2271 

2272 


Turn  on  alarm  1  indicator 
Turn  on  alarm  2  indicator 
Turn  on  alarm  3  indicator 


An  intermittent  audible  alarm  also  sounds  when  any  indicator  is  on. 


FIGURE  1(a)  TEXT  TABLE  (EXAMPLE) 


TABLE  4-01 

TAPE  FUNCTION  CODES 


binary  Bits 
29-31 


Tape  Unit  Function 


Read  Binary 
Read  bCD 
Write  Binary 
Write  BCD 
Advance  One  Record 
Write  EOF 

Backspace  One  Record 
Rewirid  to  Load  Point 


FIGURE  1(b)  FREE  TABLE  (EXAMPLE) 
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4. 2  Free  Tables.  A  free  table  has  a  closed  format  (ruled  heading  and 
columns)  and  appears  as  a  separate  page  with  its  own  title,  table  number, 
and  page  number.  The  table  will  appear  immediately  after  the  first 
reference  to  it  in  the  text.  Tables,  when  physical  size  exceeds  the  carriage 
capacity  of  the  typewriter  will  be  rendered  by  graphic  techniques  and  phyto- 
reduced  for  inclusion  in  the  final  document.  Free  tables  will  be  identified 
by  the  nomenclature  ’’TABLE  M-NN"  where  M  is  the  section  number  (first 
decimal  number)  and  NN  is  the  consecutive  count  of  tables  within  the  section. 
The  table  number  will  be  centered  at  the  top  of  the  table.  The  table  identif¬ 
ication  will  also  include  a  title  -  a  brief  summary  of  the  table  content  - 
rendered  in  upper-case  type  directly  beneath  the  table  number.  An  exam¬ 
ple  of  a  free  table  is  shown  in  Figure  1  (b)oq  the  previous  page. 

5.  ILLUSTRATIONS 

Illustrations  refer  to  the  use  of  line  work  for  diagrammatic  (flow  charts), 
geometric,  or  pictorial  representations  of  information.  Normally  such 
materials  are  produced  oversize  and  photo- reduced  for  inclusion  in  the 
final  document. 

Line  work  will  follow  the  originators  source  material  to  the  greatest  extent, 
consistent  with  left-to- right,  top-to-bottom  conventions  for  the  progression 
of  information  and  an  efficient  utilization  of  the  available  page  size.  Line 
weight  will  be  varied  to  provide  emphasis  as  required.  Annotation  of  the 
line  work  will  logically  account  for  all  the  elements  shown,  with  callouts, 
legends  and  notes  as  appropriate.  All  annotations  will  be  upper  case,  with 
character  size  (and  weight)  varied  to  provide  emphasis  as  required.  Typing 
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may  be  used  to  annotate  the  line  work  in  lieu  of  lettering  or  other  graphic 
techniques  provided  that  any  photo  reduction  involved  does  not  exceed 
2  :  1.  Typing  may  be  done  directly  on  the  original  line  work  or  on  trans¬ 
parent  material  which  is  then  cut  to  size  and  affixed  to  the  original. 

Illustrations  will  be  identified  by  the  nomenclature  "FIGURE  M-NN"  where 
M  is  the  main  section  (first  decimal  number)  where  the  figure  appears, 
and  NN  is  the  consecutive  count  of  figures  within  the  section.  The  figure 
number  will  be  centered  at  the  bottom  of  the  figure  page.  The  figure 
identification  will  include  a  title  -  a  brief  summary  of  the  content  of  the 
figure  -  directly  beneath  the  figure  number.  An  example  of  a  line  work 
illustration  is  shown  in  Figure  2. 

6.  EQUATIONS 

Equations  important  to  the  presentation  in  the  text  will  be  "displayed”  - 
placed  on  separate  lines  from  the  text.  A  sferies  of  equations  will  be 
aligned  on  the  equality  signs  and  centered  on  the  page.  Each  equation 
will  be  numbered  for  reference  using  the  nomenclature  "(M-NN),  "  where 
M  is  the  main  section  number  (first  decimal  number),  where  the  equation 
appears  and  NN  is  the  consecutive  count  of  equations  within  the  section. 

The  number  will  be  positioned  to  the  left  of  the  equation  line  and  aligned 
with  all  other  equation  numbers  which  appear  on  the  page.  An  example  of 
an  equation  "display"  is  shown  in  Figure  3. 
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6.1  Example.  The  following  set  of  equations  represents  a  system  of  4 
linear,  non- homogeneous  equations  in  3  unknowns. 


(6-01) 

allVa12x2+a13Vbl 

(6-02) 

a21xl+a22x2+a23x3=b2 

(6-03) 

a31xl+a32x2+a33x3=b3 

(6-04) 

a41xl+a42x2+a43x3=b4 

The  presentation  or  display  of  these  equations  in  paragraph  6. 1  illustrates 
the  rules  of  Section  6  preceding. 

FIGURE  3  DISPLAY  OF  EQUATIONS  (EXAMPLE) 
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7.  PAGE  NUMBERING 

■j 

7. 1  Text.  Text  pages  will  be  numbered  consecutively  in  arabic  numerals 
centered  3/8  inch  (3/4  inch  on  classified  documents)  from  the  bottom  of  the 
page.  Tables  and  illustrations  will  be  incorporated  (as  separate  pages) 
into  the  text  immediately  following  the  first  reference  in  the  text  and  will 
be  included  in  the  text  page  count.  The  last  page  of  the  text  will  carry  the 
notation:  ’’(END  OF  TEXT)"  beneath  the  page  number. 

7.2  Pre-Text.  Pre-Text  pages  will  be  numbered  consecutively  in  lower 
case  roman  numerals  starting  with  the  page  immediately  following  the  front 
cover.  However,  pages  up  to  and  including  the  title  page  will  not  carry 

an  explicit  page  number  even  though  they  are  included  in  the  pre-text  page 
count. 

7.3  Post-Text.  Post-Text  pages  up  to  but  not  including  the  appendices  will 
be  numbered  as  a  continuation  of  the  text  number  count. 

7.4  Appendices.  Appendices  will  be  individually  numbered  with  arabic 
numerals  prefixed  by  the  alphabetic  designator  for  the  appendix  or  the 
designator  ”A"  if  only  one  appendix  is  used. 
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1.  PURPOSE 

This  standard  establishes  standards  for  paper  stock,  printing,  and  binding 
of  NAVCOSSACT  documentation. 


2.  PAPER  STOCK 


2. 1  Cover.  Cover  stock  for  all  self-covered  documents  will  be  100  lb 
Antique  Finish  Cover  (JCPL20)  and  the  same  size  as  the  document  body 
page  (i.  e. ,  8  X  10-1/2).  Stock  color  will  be  determined  by  the  classifica 
tion  of  the  document  in  accordance  with  the  following  table. 


Classification 

Cover  Color 

Unclassified 

White 

Confidential 

Green 

Secret 

Yellow 

Top  Secret 

'Pink 

2. 2  Body  Stock.  Body  stock  will  be  100  lb  Offset  Book  (JCPA60)  in  the 
following  sizes. 


Size  Purpose 

8  X  10-1/2 
16  X  10-1/2 
24  X  10-1/2 


Individual  Sheets 
Single  Fold-out 
Double  Fold-out 


1 
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3.  PRINTING 


3. 1  Single  Face.  Single  face  printing  will  be  used  for  documents  consisting 
of  50  masters  or  less. 


3. 2  Double  Face.  Double  face  printing  will  be  used  for  documents  consist¬ 
ing  of  more  than  50  masters.  Right-hand  page*faces  will  be  ii$ed  for,  or 

f  1 

at  the  start  of,  the  following: 


Special  Notices 
Revision  Sheet 
Abstract 
Title  Page 
Table  of  Contents 
List  of  Illustrations 
List  of  Tables 

List  of  Abbreviations  &  Symbols 

Text  Sections 

References 

Bibliography 

Appendices 


4.  BINDING 

The  selection  of  a  binding  will  be  based  upon  the  number  of  sheets  in  the 
document  and  its  ultimate  use,  as  given  in  the  following  table. 
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Binding  Type  Number  of  Sheets  Purpose 

Staples  less  than  25  All 

Clasp/Post  25-200  Periodic  reference 

Plastic  Comb  25-150  Continuous  reference 

Looseleaf  25-100  Continuous  references 

(unclassified  and  update 

material  only) 

Documents  with  a  number  of  sheets  in  excess  of  those  given  for  a  particular 
binding  type  will  be  bound  as  a  multi-volume  set.  Page  division  among 
the  set  volumes  will  be  dictated  primarily  by  a  logical  division  of  the  text. 
However,  the  division  may  not  produce  more  than  a  2  :  1  variation  in  the 
number  of  sheets  per  volume  in  a  multi-volume  set. 


5.  NON-STANDARD  PRODUCTION 

Certain  non-standard  documentation,  such  as  machine  produced  printouts 

t 

may  be  required  in  quantity  to  accompany  standard  documentation.  In 
this  instance,  legible  1  :  1  copies  of  the  original  material  will  be  made 
and  bound  between  hard  cover  stock  for  mechanical  rigidity.  The  first 
sheet  of  the  document  will  contain  a  title  page  similar  in  format  to  Figure  1 
of  STD  20-05.  The  document  will  normally  be  identified  as  an  appendix 
to  a  standard  documeat  type  (STD  10-05).  • 
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1.  PURPOSE 

This  standard  summarizes  the  security  identification  requirements  applica¬ 
ble  to  the  preparation  of  production  copies  of  NAVCOSSACT  documentation. 
For  matters  of  security  classification  assignment  and  document  handling 
and  control  refer  to  OPNAV  Instruction  5510.  IB;  for  matters  of  document 
distribution  statements  refer  to  NAVMAT  Instruction  4000. 17. 

2.  DOCUMENT  CLASSIFICATION 

Document  classification  and  downgrading  notices  are  the  responsibility  of 
the  document  orginator  and  will  be  assigned  in  accordance  with  the  cited 
OPNAV  instruction  or  direction,  as  required,  from  the  Security  Division 
(Code  43). 

2. 1  Document  Classification.  The  classification  of  a  document,  which 
represents  the  highest  classification  of  material  (TOP  SECRET,  SECRET 
OR  CONFIDENTIAL)  appearing  in  the  document  will  be  positioned  near  the 
top  and  bottom  of  the  outside  of  the  front  and  back  covers.  The  letters  of 
the  classification  will  be  capitalized  and  rendered  larger  and  heavier  than 
the  adjacent  lettering.  Unclassified  documents  require  no  marking. 

2.2  Page  Classification.  The  classification  of  a  page,  which  represents 
the  highest  classification  of  material  (TOP  SECRET,  SECRET  OR  CON¬ 
FIDENTIAL)  appearing  on  the  page  will  be  positioned  near  th6  top  and  bottom 
of  the  page.  The  letters  of  the  classification  will  be  capitalized  and  rendered 
larger  and  heavier  than  the  adjacent  lettering. 
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2.3  Text  Classification.  The  classification  of  text  will  be  indicated  by 
the  notation:  (T)  for  TOP  SECRET,  (S)  for  SECRET  and  (C)  for  CONFI¬ 
DENTIAL  and  (U)  for  UNCLASSIFIED  immediately  to  the  left  of  the  section, 
paragraph  or  subparagraph.  Tables  and  illustrations  will  be'  individually 
classified  using  the  above  notations  immediately  to  the  left  of  the  table  or 
figure  number.  Unclassified  documents  do  not  require  text  classification. 

*  . 

2.4  Automatic  Downgrading.  The  appropriate  downgrading  status  of  each 
document  will  be  shown  in  the  lower  right  corner  of  the  front  cover  (see 
STD  20-05,  Figure  1).  The  standard  texts  to  be  used  are  given  in  Appen¬ 
dix  A. 


3.  DOCUMENT  DISTRIBUTION  STATEMENTS 

Distribution  statements  appearing  on  documentation  are  the  responsibility 
of  the  document  originator  and  will  be  assigned  in  accordance  with  the 
cited  NAVMAT  instruction  and  assistance,  as  required,  from  the  Security 
Division  (Code  43).  Documents  both  classified  and  unclassified  are  subject 
to  distribution  notices.  The  standard  distribution  texts  to  be  used  are 
given  in  Appendix  B. 
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APPENDIX  A 

AUTOMATIC  DOWNGRADING  NOTICES 


GROUP  1 


EXCLUDED  FROM  AUTOMATIC  REGRADING 
DO D  DIR  5200.10  DOES  NOT  APPLY 


EXEMPTED  FROM  AUTOMATIC  DOWNGRADING  BY: 


GROUP  2 


(APPROVING  AUTHORITY) 
DOD  DIR  5200. 10 


GROUP  3 


DOWNGRADED  AT  12- YEAR  INTERVALS 
NOT  AUTOMATICALLY  DECLASSIFIED 
DOD  DIR  5200. 10 


I - 1 


GROUP  4 


DOWNGRADED  AT  3-YEAR  INTERVALS 
DECLASSIFIED  AFTER  12  YEARS 
DOD  DIR  5200. 10 
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APPENDIX  B 

DISTRIBUTION  NOTICES 

Statement  No. 


DISTRIBUTION  OF  THIS 
DOCUMENT  IS  UNLIMITED 


If  Document  is  Unclassified: 


Statement  No. 


THIS  DOCUMENT  IS  SUBJECT  TO  SPECIAL 
EXPORT  CONTROLS  AND  EACH  TRANS¬ 
MITTAL  TO  FOREIGN  GOVERNMENTS  OR 
FOREIGN  NATIONALS  MAY  BE  MADE  ONLY 
WITH  PRIOR  APPROVAL  OF 

(Controlling  DOD  Office) 

(fill  in) 


-  OR  - 


If  Document  is  Classified: 


IN  ADDITION  TO  SECURITY  REQUIREMENTS 
WHICH  MUST  BE  MET,  THIS  DOCUMENT  IS 
SUBJECT  TO  SPECIAL  EXPORT  CONTROLS 
AND  EACH  TRANSMITTAL  TO  FOREIGN 
GOVERNMENTS  OR  FOREIGN  NATIONALS 
MAY  BE  MADE  ONLY  WITH  PRIOR  APPROV¬ 
AL  OF  (Controlling  DOD  Office) 

(fill  in) 
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:ement  No.  3  If  Document  is  Unclassified: 


EACH  TRANSMITTAL  OF  THIS  DOCUMENT 
OUTSIDE  THE  AGENCIES  OF  THE  U.  S. 
GOVERNMENT  MUST  HAVE  PRIOR  APPROV¬ 
AL  OF  (Controlling  DOD  Office) 

(fill  in) 


r  or  - 

If  Document  is  Classified: 


IN  ADDITION  TO  SECURITY  REQUIRE¬ 
MENTS  WHICH  APPLY  TO  THIS  DOCUMENT 
AND  MUST  BE  MET,  EACH  TRANSMITTAL 
OUTSIDE  THE  AGENCIES  OF  THE  U.  S 
GOVERNMENT  MUST  #AVE  PRIOR  APPROV¬ 
AL  OF  (Controlling  DOD  Office) 
_ (fill  in) _ 


tement  No.  4  If  Document  is  Unclassified: 


EACH  TRANSMITTAL  OF  THIS  DOCUMENT 
OUTSIDE  THE  DEPARTMENT  OF  DEFENSE 
MUST  HAVE  PRIOR  APPROVAL  OF 
(Controlling  DOD  Office) 

(fill  in)  • 


-  OR  - 

If  Document  is  Classified: 


IN  ADDITION  TO  SECURITY  REQUIREMENTS 
WHICH  APPLY  TO  THIS  DOCUMENT  AND 
MUST  BE  MET,  EACH  TRANSMITTAL  OUT¬ 
SIDE  THE  DEPARTMENT  OF  DEFENSE 
*MUST  HAVE  PRIOR  APPROVAL  OF 
(Controlling  DOD  Office) 

_  (fill  in) 
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APPENDIX  B  (Cont'd) 


If  Document  is  Unclassified: 


THIS  DOCUMENT  MAY  BE  FURTHER 
DISTRIBUTED  BY  ANY  HOLDER  ONLY 
WITH  SPECIFIC  PRIOR  APPROVAL  OF 
(Controlling  DOD  Office) 

(fill  in) 


-  OR  - 


If  Document  is  Classified: 


IN  ADDITION  TO  SECURITY  REQUIRE¬ 
MENTS  WHICH  APPLY  TO  THIS  DOCU¬ 
MENT  AND  MUST  BE  MET,  IT  MAY  BE 
FUTHER  DISTRIBUTED  BY  THE  HOLDER 
ONLY  WITH  SPECIFIC  PRIOR  APPROVAL 
OF  (Controlling  DOD  Office) 

(fill  in) 
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PURPOSE 


deferable  NAVCOSSACT  documents  and  programming  materials. 


DELIVERABLE  ITEMS 


Dcome  ntation.  Each  deliverable  package  will  includ 

%• 

reproducible  master  of  each  programming  document  p 
wrct  d^i  f-iopment. 

Materials.  Each  deliverable  package  will  include  the  materials 
:  died  .1  Par agraphs  2.  2. 1  and  2.  2.  2  below. 


a  a  minimum  of 
reduced  during 


1  P-cgritn  Listirg.  A  separate  listing  of  each  prograip  on  four-part 
=  r  as  woP.  as  a  consolidated  master  listing  of  all  program  packages 
maliy  in  the  computer  during  operation.  Utility  and  Diagnostic  routines 
listed  separately.  If  available,  a  listing  of  outputs  froip  test  runs  should 
resided 


2  Pregram  Decks  and  Tapes.  A  program  deck  and  two  tapes  will  be 
jded  <n  both  symbolic  and  binary  form.  The  binary  deck  and  tapes  will 
n  a  frrm >t  suitable  for  immediate  use  by  operating  personnel. 
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1.  PURPOSE 

To  establish  the  numbering  system  for  NAVCOSSACT  programming  docu¬ 
mentation. 

2.  DOCUMENT  NUMBERING 

The  document  number  will  be  a  two-line  number.  On  the  first  line  will  be 
the  project  number  under  which  the  documentation  is  produced;  the  second 
line  will  contain  a  control  number  assigned  by  the  Project  Leader  to 
identify  the  individual  documents.  The  following  two-line  number  is  an 
example  of  a  document  number. 

NAVCOSSACT  DOCUMENT  NO. 

90A012 

ODP04A 

2. 1  Project  Number.  The  alphanumeric  identifier  for  the  project  assigned 
per  QPNAV  Instruction  5230. 1A,  Appendix  B. 

2.2  Control  Number.  The  control  number  consists  of  the  following 
elements: 

a.  Document  Classification.  A  sequence  of  zeros  to  identify  the 
security  level  as  follows: 


Top  Secret 

000 

Secret 

00 

Confidential 

0 

Unclassified 

(None) 
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Irv  Document  Type.  A  two-letter  mnemonic  corresponding  to  the 
document  type  as  given  in  the  following  table: 


Document  Type 

System 

Preliminary  Functional  Description 
Data  Requirements  Document 


Mnemonic 

SD 

SR 


Design 

Subsystem  Specification  DS 

Program  Specification  DP 

Data  Base  Specification  DB 

Manuals 

Project  Manual  MP 

Staff  Manual  MS 

Operations  Manual  MO 

Program  Maintenance  Manual  MM 

Test 

Acceptance  Test  Plan  TP 

Acceptance  Test  Analysis  Report  TR 


SUBJECT 

DOCUMENT  NUMBERING 

c.  .  Document  Type  Count.  A  two  digit  code  starting  from  01  assigned 

from  a  consecutive  count  of  the  documents  of  the  same  document 
type  generated  on  the  project. 

d.  Document  Revision  Identification.  An  alphabetic  for  each  revision 
starting  with  A  for  the  first  revision. 

2.3  Document  Number 

NAVCOSSACT  DOCUMENT  NO. 

90A012 

.ODP04A 

The  above  example  describes  the  A  revision  of  the  fourth  Programming 
Specification  prepared  on  NAVCOSSACT  Project  No.  90A012. 
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fRPOSE 

ablish  the  procedure  for  review  and  approval  of  NAVCOSSACT  pro- 
ning  documentation. 

EDITIONS 

v  and  approval  under  this  standard  will  be  undertaken  when  a  document 
liable.  The  document  will  be  in  essentially  its  final  form  with  respect 
l  format  and  technical  content. 

SCHNICAL  REVIEW  AND  APPROVAL 

ipleted  document  will  be  distributed  for  technical  review  and  approva1 
the  originating  department.  Technical  review  addressees  for 
lent  type  are  given  in  Table  1  at  the  end  of  this  Standard.  Review 
ents  will  be  incorporated  in  the  document  and  the  document,  will  be: 

.  Distributed  for  general  NAVCOSSACT  and  USER  reference  per 
STD  30-15.  General  distribution  following  approval  at  the  technical 
level  is  only  applicable  to  program  design  documentation,  which  re¬ 
quires  no  further  approvals. 

.  Prepared  for  NAVCOSSACT- level  approval  per  the  following 
Section  4. 

AVCOSSACT  REVIEW  AND  APPROVAL 

npleted  document  which  has  received  technical  approval  will  be  dis- 
ed  for  NAVCOSSACT-level  review  and  approval.  NAVCOSSACT  review 
■ssees  for  each  document  type  are  given  in  Table  1.  Review  comments 
te  incorporated  in  the  document  and  the  document  will  be: 
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To  establish  the  procedure  for  review  and  approval  of  NAVCOSSACT  pro¬ 
gramming  documentation. 


2.  CONDITIONS 

Review  and  approval  under  this  standard  will  be  undertaken  when  a  document 
is  available.  The  document  will  be  in  essentially  its  final  form  with  respect 
to  both  format  and  technical  content. 


3.  TECHNICAL  REVIEW  AND  APPROVAL 

A  completed  document  will  be  distributed  for  technical  review  and  approva 
within  the  originating  department.  Technical  review  addressers  for  caq|i 
document  type  are  given  in  Table  1  at  the  end  of  this  Standard.  Review 
comments  will  be  incorporated  in  the  document  and  the  document,  will  be 

a.  Distributed  for  general  NAVCOSSACT  and  USER  reference  per 

STD  30-15.  General  distribution  following  approval  at  the  technical 
level  is  only  applicable  to  program  design  documentation,  which  re¬ 
quires  no  further  approvals. 

b  Prepared  for  NAVCOSSACT- level  approval  per  the  following 
Section  4. 

4.  NAVCOSSACT  REVIEW  AND  APPROVAL 

A  completed  document  which  has  received  technical  approval  will  be  dis¬ 
tributed  for  NAVCOSSACT- level  review  and  approval.  NAVCOSSACT  review 
addressees  for  each  document  type  are  given  in  Table  1.  Review  comments 
will  be  incorporated  in  the  document  and  the  document  will  be: 
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SUBJECT 


DOCUMENT 
REVIEW  &  APPROVAL 


j|  NUMBER 
'  30-10 


a.  Distributed  for  general  NAVCOSSACT  (only)  reference  per  STD 
30-15. 

b.  Prepared  for  USER- level  approval  per  the  following  section. 


USER  REVIEW.  AND  APPROVAL 


A  completed  draft  document  which  has  received  NAVCOSSACT  approval  will 
be  distributed  for  USER-level  review  and  approval.  USER  addresses  for 
each  document  type  are  given  in  Table  1.  Reference  distribution  of  the  doc¬ 
ument  will  be  made  to  all  NAVCOSSACT  and  USER  personnel  per  STD  30-15. 
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1.  PURF  *SE 

To  establish  standard  distribution  lists  for  programming  documentation 
which  is  in  its  final  smooth  form. 


2.  DISTRIBUTION  LISTS 

Distribution  lists  which  include  the  number  of  addressee  copies  are  given 
in  Table  1. 


Documentation 
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1.  PURPOSE 

To  establish  the  procedure  for  executing  changes  to  NAVCOSSACT  program¬ 
ming  documentation. 

2.  CONDITIONS  AND  PROCEDURES 

Changes  within  the  scope  of  this  procedure  are  those  made  against  existing 
approved  documentation,  not  those  in  the  process  of  initial  preparation. 

a.  Conditions.  The  change  can  be  accomplished  within  the  require¬ 
ments  of  the  PFD  and  within  the  existing  project  schedule  (man¬ 
power  constant). 

Procedures.  Initiate  a  technical  review  and  approval  cycle  per 
STD  30-10.  No  other  action  required. 

b.  Conditions.  The  change  can  be  accomplished  with;  the  require¬ 
ments  of  the  PFD,  butnot  within  the  existing  project  schedule 
(manpower  constant). 

Procedures.  Assess  schedule  impact,  advise  user.  As  approved, 
initiate  a  technical  review  and  approval  cycle  per  STD  30-10. 

c.  Conditions.  The  change  cannot  be  accomplished  within  the  require¬ 
ments  of  the  PFD  but  can  be  accomplished  within  the  existing 
project  schedule  (manpower  constant). 

Procedures.  Assess  scope  impact,  advise  user.  As  approved, 
initiate  a  sequence  of  technical,  NAVCOSSACT,  User  review  and 
approval  cycles. 
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d.  Conditions.  The  change  cannot  be  accomplished  within  the  require¬ 
ments  of  the  PFD  or  within  the  existing  project  schedule  (manpov/er 
constant). 

Procedures.  Assess  total  impact,  advise  user.  As  approved, 
initiate  a  sequence  of  technical,  NAVCOSSACT,  User  review  and 
approval  cycles. 
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1.2.1 
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Section  2 
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Section  2 


2.3.1 

2.3.2 

2.3.3 

2.3.4 

2.3.5 
2.4 
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GENERAL  SPECIFICATION  INFORMATION 
Purpose  of  Specification 
Scope  of  Specification 
General 

Reader  Orientation 

CONTENT  OF  PFD 
GENERAL 

Purpose  of  Preliminary  Functional 
Description 
Project  Reference 
Applicable  Documents 

scope  ■; 

General  System  Description 
Existing  Methods  and  Procedures 
Proposed  Methods  and  Procedures 
Summary  of  Improvements 
Summary  of  Impacts 
Specific  Performance  Requirements 
System  Functions 
Data  Base  Magnitude 
Problem  Areas  Requiring  Further 
Analysis 
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SUBJECT 

preliminary 

FUNCTIONAL  DESCRIPT  BON 

1.  GENERAL  SPECIFICATION  INFORMATION 

1.1  Purpose  of  Specification.  This  documentation  specification  provides 
guidance  for  the  preparation  of  Preliminary  Functional  DescriptlonB(PFD). 
A  PFD  is  normally  required  for  every  system  developed  by  NAVCOSSACT. 


1.2  Scope  of  Specification 

1.2. 1  General.  Each  PFD  shall  include  the  Information  starting  with 
Section  1.  GENERAL  below  in  order  presented  in  this  specification  and 
under  the  paragraph  titles  specified.  All  paragraphs  are  not  applicable 

to  every  system  for  which  a  PFD  is  written  and  portions  not  pertinent 

'  •» 

to  a  particular  system  may  be  designated  as  not  applicable  by  the  Project 
Leader.  (For  example,  paragraph  2.3.5  on  Data  Base  Magnitude  may 
be  eliminated  from  PFD’s  for  systems  which  do  not  process  data.) 

1.2.2  Reader  Orientation.  The  PFD  is  a  management  tool  for  use  by 
many  non-ADP  personnel  and  must  be  written  in  non-technlcal  language. 
It  should  be  oriented  toward  the  non-ADP  reader  since  all  elements  of 
the  document  will  be  subject  to  review  by  non-technical  staff  personnel. 

2.'  CONTENT  OF  PFD 

The  content  of  the  PFD  shall  be  in  accordance  with  the  format  on  the 
following  pages. 


NUMBER 
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1.  GENERAL 

1.1  Purpose  of  Preliminary  Functional  Description.  Paragraph  1. 1 
shall  describe  the  purpose  of  the  PFD.  The  description  will  be  in 
accordance  with  the  following  NAVCOSSACT  objectives  for  preparation 
of  a  PFD: 

a.  Provide  in  writing  the  system  requirements  as  a  basis  for 
mutual  understanding  between  the  user  and  the  developer. 

b.  Provide  a  definition  of  performance  requirements  and 
preliminary  design. 

c.  Define  the  work  to  be  accomplished. 

d.  Provide  a  basis  for  the  development  of  system  tests. 

1. 2  Project  Reference.  Paragraph  1. 2  shall  state  the  project  title  and 

number  and  provide  a  brief  summary  of  the^projject  objectives.  This 

1  . 

paragraph  will  also  identify  the  project  sponsor  ^nd  user(s). 

I 

1.3  Applicable  Documents.  Paragraph  1.3  shall  provide  a  list  of 
applicable  documents  by  number  and  title.  This  paragraph  will  include 
at  least  the  following  when  applicable: 

Project  Request 

Feasibility  Study  Documentation 

Related  Projects'  Documentation 
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2.  SCOPE 

2.1  General  System  Description.  Paragraph  2. 1  shall  provide  a  general 
description  of  the  system.  It  shall  include  a  statement  of  the  type  of 
system,  i.  e. ,  functional  or  support,  as  well  as  the  general  classifica¬ 
tion  of  the  system  such  as  accounting,  inventory  control,  or  command 
and  control  for  a  functional  system  or  compiler,  master  control,  or 
general  utility  for  a  support  system.  A  statement  of  major  performance 
requirements  or  goals  will  also  be  included  if  available.  The  descrip¬ 
tion  will  also  include  the  designator  and  title  of  the  organization  which 
will  use  the  system,  e.g. ,  J201-CINCPAC  Intelligence  Library. 
Reference  will  be  made  to  higher  order  and  parallel  systems  and  their 
documentation  as  required  to  enhance  the  general  description  of  the 
system.  This  paragraph  will  also  include  a  description  of  the  relation¬ 
ships  between  the  capability  being  developed  and  other  related  capa¬ 
bilities  currently  under  development.  When  applicable  there  will  be  a 
statement  concerning  any  related  events  for  which  this  system  is 
required  including  exercises  and  impending  military  operations.  The 
description  will  also  identify  anticipated  operational  changes  that  will 
affect  the  system  as  well  as  planned  cyclic  updating  of  the  system. 

2. 2  Existing  Methods  and  Procedures.  Paragraph  2. 2  shall  provide  a 
brief  description  of  the  methods  and  procedures  presently  employed  by 
the  originator  of  the  Project  Request.  Included  in  the  description  will 
be  personnel  responsibilities,  equipment,  inputs  and  outputs,  volumes, 
frequencies,  and  time  delays.  This  paragraph  will  include  quantitative 
„  as  well  as  qualitative  values.  A  System  Information  Flow  Chart  (in 
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accordance  with  Standard  50-15)  depicting  data  flow  from  data  acquisi¬ 
tion  through  its  processing  and  eventual  output  will  be  provided.  If  a 
description  of  existing  methods  and  procedures  is  not  applicable  it  may 


be  excluded  at  the  discretion  of  the  Project  Leader. 


2.3  Proposed  Methods  and  Procedures.  Paragraph  2.3  shall  provide 

a  description  of  the  proposed  system.  The  description  of  the  proposed 

system  will  include  a  presentation  of  the  proposed  capabilities  and,  if 

applicable,  a  comparison  with  the  existing  system  emphasizing  the 

differences.  This  paragraph  will  include  a  statement  of  limitations 

affecting  the  desired  capability  including  the  prediction  of  expected  types 

of  errors.  When  tools,  techniques,  and  procedures  from  other  systems 

•» 

will  be  utilized  with  or  will  become  a  part  of  the  proposed  system,  these 
will  be  appropriately  presented  in  this  description.  A  System  Informa¬ 
tion  Flow  Chart  (in  accordance  with  Standard  50-15)  will  be  provided 
to  present  an  over-all  view  of  the  planned  capabilities.  In  addition  an 
Integrated  ADP  Flow  Chart  and  System  Organization  Chart  will  be 
included  in  subparagraphs  of  section  2.3  wherever  they  best  complement 
the  narrative.  Paragraph  2.3  may  also  include  a  discussion  of  alterna¬ 
tive  methods  and  procedures  when  appropriate.  For  example,  if  the 
proposed  system  does  not  correspond  to  one  required  in  the  Project 
Request,  a  discussion  of  the  rationale  for  the  alternative  solution  and  a 
description  of  the  evaluation  criteria  may  be  given. 


2.3. 1  Summary  of  Improvements.  Paragraph  2.3. 1  shall  provide  a 
summary  of  benefits  to  be  obtained  from  the  proposed  system.  A  summa¬ 
tion  of  any  deficiencies  in  the  existing  system  and  a  summation  of  addi¬ 
tional  capabilities  required  along  with  appropriate  explanations  may  be 
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provided.  Explicitly  identified  will  be  those  capabilities  which  will  be 
provided  by  the  proposed  system.  A  required  capability  may  be  based 
upon  the  opportunity  to  improve  existing  methods  and  procedures.  If  so, 
the  extent  of  the  anticipated  improvements  will  be  stated.  There  will 
also  be  explicit  Identification  of  any  required  capabilities  which  will  not 
be  provided  by  the  proposed  system  Including  capabilities  which  are 
currently  being  provided  by  the  existing  system.  Capabilities  that  are 
only  partially  provided  will  be  so  stated  and  appropriately  described. 

This  paragraph  may  also  include  a  comparison  of  transaction  time  cycles 
of  the  existing  and  proposed  systems.  The  discussion  will  include 
functional  improvements  (new  capabilities),  improvements  of  degree 
(upgrading  existing  capabilities),  and  temporal  improvements  (decreased 


response  time  or  processing  time). 


2. 3. 2  Summary  of  Impacts.  This  paragraph  shall  describe  the 
anticipated  impacts  on  the  existing  equipmeht,  software,  organizational, 
and  operational  environments  as  well  as  development  impacts. 


a.  Equipment  impacts  will  include  additions  and  modifications 
to  the  currently  available  configuration  and  the  operational 
time  requirements  to  be  imposed  on  the  equipment.  Reference 
shall  be  made  in  this  paragraph  to  the  specific  equipment 
capabilities  outlined  in  paragraph  3. 1  of  the  PFD. 

b.  Software  impacts  will  Include  additions  and  modifications  to 
existing  operational  and  support  software  packages  necessary 
to  adapt  them  to  the  new  system. 


SUBJECT 
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c.  Organizational  impacts  may  include  modification  in  positional 
functions  and  additional  positional  functions  to  Implement  the 
new  system;  both  staff  and  operator  functions  will  be  covered. 
These  impacts  will  include  items  such  as  manoower  to  maintain 
the  data  base  and  manpower  to  operate  and  maintain  the  programs. 

d.  Operational  impacts  will  include  changes  in  both  staff  and 
operations  center  procedures  to  use  the  new  system;  considered 
will  be  impacts  on  the  relationship  of  the  operations  center  and 
the  user,  impacts  on  the  operational  procedures  of  the  opera¬ 
tions  center,  operational  similarities  with  other  systems,  new 
data  sources,  quantity  and  type  of  data  to  be  provided,  data 
retentions  and  data  retrieval,  reporting  intervals,  methods  of 
reporting,  and  modes  of  operation  of  the  user  such  as  peace 
time,  alert,  and  wartime.  Also  included  will  be  recommended 
methods  for  providing  data. 

e.  Development  impacts  will  Include  estimates  of  all  user  require¬ 
ments  necessary  to  initiate  the  system  such  as  manpower 
required  to  develop  the  d?ta  base  and  operator  and  machine 
time  necessary  for  system  test.  This  paragraph  will  also 
Identify  the  requirement  to  develop  conversion  programs  for 
modifying  existing  data  files  required  by  the  new  system. 

2.3.3  Specific  Performance  Requirements.  Paragraph  2.3.3  shall 
describe  the  specific  performance  requirements  to  be  satisfied  by  the 
system.  This  presentation  will  be  a  delineation  of  requirements,  evolved 
from  the  system  analysis,  on  which  the  system  design  is  to  be  based. 

The  requirements  will  be  stated  in  such  a  manner  that  system  functions 
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and  system  test  can  be  related  to  them.  A  quantitative  presentation  of 
requirements  will  be  included  such  as  the  number  of  tracks  a  system  is 
to  handle  for  a  functional  system  or  the  number  of  program  systems  to  be 
supervised  by  a  master  control  system. 


2. 3. 4  System  Functions.  Paragraph  2.3.4  shall  describe  the  systrnn 
functions.  This  paragraph  will  show  how  the  aggregate  of  the  system 
functions  satisfy  the  specific  requirements  in  paragraph  2. 3. 3.  For 
large  projects,  this  paragraph  will  relate  system  functions  to  appropriate 
subsystems.  For  small  systems,  this  paragraph  will  relate  functions  to 
programs  where  possible. 


2.3.5  Data  Base  Magnitude.  This  paragraph  shall  provide  an  estimate 
of  the  number  and  size  of  data  elements  to  be  included  in  the  system  data 
base,  jit  will  provide  an  enumeration  of  the  different  types  of  data 
elements  by  name  and  size  and  an  estimate  Of  total  storage  required 

i  '  ' 

based  on  a  summation  of  the  requirements  for  the  different  types  of 
elementl. 


2.4  Problem  Areas  Requiring  Further  Analysis.  Paragraph  2.4  shall 
provide  a  description  of  problems  requiring  further  analysis.  For  each 
problem  this  will  include  a  definition  of  the  problem,  the  approach  to  be 
taken  in  solving  the  problem,  the  anticipated  time  when  the  solution  will 
be  available,  and  the  impacts  on  the  PFD  based  on  the  possible  results. 
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3.  ENVIRONMENT 

3. 1  Equipment  Environment.  Paragraph  3. 1  shall  provide  a  description 
of  the  equipment  capabilities  required  for  the  system.  This  paragraph 
will  present  descriptions  of  the  equipment  presently  available  and 
characteristics  of  any  new  equipment  necessary.  A  guideline  for  equip¬ 
ment  to  be  described  follows: 

Equipment  Configuration 

Processor(s)  including  number  of  each  on-line. 

Storage  media  (estimated  quantity  of  core,  drum,  disk,  and 
tape  storage). 

Output  devices  including  number  of  each  on-line. 

Input  devices  including  number  of  each  on-line. 

Communications  net  including  line  speeds. 

3.2  Software  Environment.  Paragraph  3.2  shall  provide  a  description 
of  the  software  environment.  There  shall  be  included  the  correct 
nomenclature  and  documentation  references  of  each  software  system, 
subsystem,  and  program  with  which  the  subject  system  will  interact. 
These  will  include  operational  and  support  software.  Test  software  may 
be  included  at  discretion  of  the  Project  Leader.  In  addition,  there  will 
be  a  description  of  the  program  language  to  be  used  by  the  system. 

3.3  System  Interfaces.  Paragraph  3.3  shall  provide  a  description  of  the 
interfaces  with  other  systems  including  systems  of  other  operational 
functions  and  other  commands  as  well  as  interfaces  with  other  internal 
program  systems.  For  each  interface,  the  following  shall  be  specified: 
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Description  of  operational  implications  of  transfer  including 
security. 

General  description  of  data  transfer  requirements  to  from 
the  subject  program. 

Current  formats  of  interchanged  data. 

•  .  _ _ _ 

Type  of  anticipated  interface  such  as  manual  or  automatic. 

Anticipated  interface  procedures. 

3. 4  Timing.  This  paragraph  shall  provide  a  description  of  the  timing 
requirements  placed  on  the  system,  if  they  are  available.  The  following 
timing  requirements  can  be  considered: 

»• 

Throughput  time. 

Response  time  of  major  system  functions. 

Cyclical  and  temporal  relations  of  functions. 

Priorities  imposed  by  types  erf  inputs  and  changes  in  modes  of 
operation. 

Response  time  to  queries,  to  threshold  values,  to  parameterized 
cycles,  and  to  update  of  data  files. 

Timing  requirements  for  the  range  of  traffic  load  under  varying 
operating  conditions. 

Interleaving  requirements  for  sequencing  and  interleaving 
programs  and  program  systems  including  the  requirement 
for  interrupting  a  program's  operation  without  loss  of  data. 
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3.5  Accuracy.  Paragraph  3. 5  shall  provide  a  description  of  accuracy 
requirements  placed  upon  the  system.  Each  type  of  system  must  consider 
the  following  items  which  will  be  expressed  in  user  terms: 


Accuracy  requirements  of  numerical  input  and  output  data. 
Accuracy  requirements  of  mathematical  calculations. 

Logical  and  legal  accuracy  of  alphanumeric  data. 

Accuracy  of  transmitted  data. 

3.  6  Security.  Paragraph  3.6  shall  describe  the  classified  elements 
of  the  system  including  inputs,  outputs,  or  data  base.  Consideration  will 
be  given  to  the  combining  of  lower  classified  items  to  produce  a  higher 
classified  element.  This  paragraph  will  include  the  level  of  classification 
of  classes  of  items,  the  identification  of  the  classifying  agency,  and  the 
handling  requirements  for  the  classified  material.  In  general,  this 
paragraph  will  not  be  applicable  to  support  systems  but  will  be  applicable 
to  functional  systems. 

3.  7  Failure  Contingencies.  Paragraph  3.7  shall  provide  a  description  of 
failure  contingencies.  There  shall  be  included  as  appropriate: 

a.  The  "back-up"  technique  for  insuring  achievement  of  the  system 
function  (Para.  2.2,4).  "Back-up"  as  used  means  the  redundancy 
available  in  the  event  the  primary  system  element  goes  down. 

A  back-up  technique  for  a  tape  output  would  be  a  card  output. 


SUBJECT 

PRELIMINARY 
FUNCTIONAL  DESCRIPTION 

b.  The  ’•fallback1'  techniques  for  insuring  achievement  of  the 
specific  requirements  of  the  system.  "Fallback"  as  used 
means  the  use  of  another  system  or  other  means  to  accomplish 
the  system  requirements.  For  example,  a  manual  system 
would  provide  a  fallback  mode  for  a  program  system: 

c.  The  "restart"  capability  for  insuring  effective  and  efficient 
recovery  from  a  failure.  The  "restart"  capability  is  a 
program  capability  to  resume  execution  of  a  program  from  the 
point  in  the  program  at  which  an  interrupt  occurred. 
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The  bibliography  will  provide  a  list  of  direct  and  indirect  references 
which  are  worthy  of  note  by  the  readers.  Each  entry  will  contain  Title, 
Date,  Document  Number  and  Classification,  Author,  and  Publisher  if 
applicable.  The  title  of  books,  papers,  reports,  and  pamphlets,  will  be 
underscored;  the  titles  of  articles  within  a  publication  will  be  placed  in 
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APPENDIX 

SYSTEM  ABBREVIATIONS,  MNEMONICS,  AND  TERMS 

The  Appendix  will  provide  the  definitions  of  terms  or  phrase  definitions 
which  carry  connotations  unique  to  this  particular  system  or  which  are 
not  sufficiently  standard  as  to  be  adequately  defined  in  standard 
dictionaries.  Item  names  and  location  tags  utilised  by  the  various 
programs  of  the  system  will  specifically  not  be  Included  in  the  Appendix; 
these  are  to  be  completely  defined  in  the  body  of  the  specification.  The 
Appendix  Is  intended  primarily  to  provide  definitions  of  terms  to  be 
found  in  the  documentation  writing  and  not  of  terms  unique  to  specific 
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1.  GENERAL  SPECIFICATION  INFORMATION 


1. 1  Purpose  of  Specification.  This  documentation  specification  provides 
guidance  for  the  preparation  of  Subsystem  Specifications.  A  subsystem 
specification  is  required  for  each  subsystem  of  a  large  system  that  is 
broken  down  into  two  or  more  subsystems.  A  subsystem  is  herein  defined 
as  the  logical  breakdown  of  a  system  into  separate  areas  of  responsibility, 
such  as  functions,  where  each  breakdown  is  composed  of  a  program  or 
series  of  piograms. 

1.2  Scope  of  Specification. 

» 

1.2. 1  General.  Each  Subsystem  Specification  shall  include  the  informa¬ 
tion  starting  with  Section  1.  GENERAL  below  in  the  order  presented  in 
this  specification  and  under  the  paragraph  titles  specified.  All  paragraphs 
are  not  applicable  to  every  subsystem  for  wh’ich  a  Subsystem  Specification 
is  written  and  portions  not  pertinent  to  a  particular  subsystem  may  be 
designated  as  not  applicable  by  the  Project  Leader.  The  Subsystem  Specif¬ 
ication  may  present  modifications  from  the  Preliminary  Functional  De¬ 
scription  (PFD),  and  it  should  be  noted  that  any  modification  to  the  scope 
of  the  system  effort  must  be  submitted  as  changes  to  the  PFD  in  accordance 
with  Standard  30-20. 

1. 2.  2  Reader  Orientation.  The  Subsystem  Specification  is  a  technical 
ADP  document  prepared  for  systems  personnel.  It  is  to  be  as  detailed  as 
possible  concerningthe  environment  and  design  elements  in  order  to  provide 
maximum  guidance  to  the  program  design  effort.  This  document  also 
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defines  subsystem  inter-relationships.  It  may  be  prepared  by  the  Project 
Leader  or  subsystems  personnel  to  guide  subsystem  development.  The 
Subsystem  Specification  may  appear  to  carry  forward  excessive  redundant 
material  from  the  PFD;  however,  it  is  anticipated  that  the  Subsystem  Speci¬ 
fication  will  present  more  detailed  data  as  a  result  of  the  continuing  design 
effort.  Furthermore,  a  Subsystem  Specification  will  only  consider  those 
segments  of  the  PFD  that  are  applicable  to  the  particular  subsystem. 

2.  CONTENT  OF  SUBSYSTEM  SPECIFICATION 

The  content  of  the  Subsystem  Specification  shall  be  in  accordance  with  the 
format  on  the  following  pages. 
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GENERAL 

i  Purpose  of  Subsystem  Specification.  Paragraph  1. 1  shall  describe 
le  purpose  of  the  Subsystem  Specification.  The  description  will  be  in 
:cordxnce  wi*h  *he  following  NAVCOSSACT  objectives  for  preparation  of 
Subsystem  Specification1 


a.  Reflect  an  intermediate  level  of  requirements  to  permit  inde¬ 
pendent  development  of  the  subsystem. 

b.  Communi-  .e  details  of  the  on-going  analysis  to  the  user  opera¬ 
tional  personnel  for  their  edificar  ion,  not  concurrence. 

c  Allow  comp!  'tion  of  the  PFD  by  deferring  the  detailed  definition 
of  the  subsystem  requirements  to  thi '  document, 
d.  Define  the  inter-relationships  among  s  lbsystems. 

.2  Project  Reference.  Paragraph  1. 2  shall  state  the  project  title  and 
umber  and  provide  a  brief  summary  of  the  project  objectives.  This 
aragraph  will  also  identify  the  project  sponsor  and  user(s). 

.3  Applicable  Documents.  Paragraph  1.3  shall  provide  a  list  of  applicable 
locuments  by  number  and  title.  This  paragraph  will  include  at  least  the 
ollowing  when  applicable: 


Preliminary  Functional  Description 
Related  Subsystem  Specifications 
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] 

2.  SCOPE 

2. 1  Subsystem  Description.  Paragraph  2. 1  shall  provide  a  general 
description  of  the  subsystem  to  establish  a  frame  of  reference  for  the 
remainder  of  the  document.  Itj  shall  include  a  summary  of  the  system 
description  in  paragraph  2. 1  of  the  Preliminary  Functional  Description 
(PTO  as  relates  to  system  type,  i.  e. ,  functional  or  support,  as  well  as 
the  general  classification  of  the  system  such  as  accounting,  inventory 
control,  or  command  and  control  for  a  functional  system  or  compiler, 
master  control,  or  general  utility  for  a  support  system.  The  description 
will  also  include  the  designator  and  title  of  the  organization  which  will  use 
the  system,  e.g. ,  J201-CINCPAC  Intelligence  Library.  Reference  will 
be  made  to  paragraph  2.3.4  of  the  PFD  for  descriptions  of  any  inter- 

#  i  ■ 

subsystem  function  relationships.  Also  referenced  will  be  the  parallel 
subsystems  and  their  documentation  as  required  to  enhance  the  general 
description  of  the  subsystem. 

2.2  Specific  Performance  Requirements.  Paragraph  2.2  shall  describe 

| 

the  specific  requirements  to  be  satisfied  by  the  subsystem.  These  shall 
be  taken  directly  from  the  system  specific  performance  requirements 
enumerated  in  paragraph  2.3.3  of  the  PFD  and  related  to  the  subsystem 
through  paragraph  2.3.4.  There  will  be  both  qualitative  and  quantitative 
descriptions  of  how  the  subsystem  satisfies  the  requirements.  If  a  sub¬ 
system  does  not  in  itself  fulfill  specific  requirements,  but  is  used  in 
conjunction  with  other  subsystems  to  fulfill  requirements,  this  fact  shall  be 
noted  in  the  presentation  with  a  statement  showing  how  the  aggregate  of 
subsystems  completely  satisfies  the  total  requirements. 
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2.3  Subsystem  Functions.  Paragraph  2.3  shall  describe  the  subsystem 
functions.  These  shall  be  taken  directly  from  the  system  functions 
enumerated  in  paragraph  2.3.4  of  the  PFD.  There  will  be  both  qualitative 
and  quantitative  descriptions  of  how  the  subsystem  satisfies  the  functions. 

If  a  subsystem  does  not  in  itself  satisfy  system  functions,  but  is  used  in 
conjunction  with  other  subsystems  to  satisfy  system  functions,  this  fact 
shall  be  noted  in  the  presentation  with  a  statement  showing  how  the  aggre¬ 
gate  of  subsystems  completely  satisfies  the  system  functions.  Although 
subsystem  function  descriptions  may  be  refined  and  more  detailed  as  a 
result  of  the  on-going  analysis  and  design,  they  must  maintain  direct 
relationship  to  the  system  functions,  and  they  must  be  stated  In  such  a 
manner  that  the  subsystem  environment  cairbe  related  to  them. 

2.4  Physical  Description.  This  paragraph  shall  present  the  data  flow 
for  the  subsystem.  Charts  providing  greater  detail  will  be  included  in 
Section  4.  DESIGN  DATA.  This  paragraph  will  provide  integrated  ADP 
Flow  Charts  for  the  subsystem  prepared  in  accordance  with  Standard  50-15. 
As  a  result  of  the  on-going  design  effort,  these  charts  may  differ  from  the 
related  charts  in  paragraph  2. 3  of  the  PFD.  However,  variations  from 

the  PFD  charts  should  be  explicitly  identified. 

3.  ENVIRONMENT 

3. 1  Equipment  Environment.  Paragraph  3. 1  shall  provide  a  description 
of  the  equipment  capabilities  required  for  the  subsystem.  This  paragraph 
will  present  descriptions  of  any  new  equipment  presently  available  and 
characteristics  of  any  new  equipment  nsoessary.  A  guideline  for  equip¬ 
ment  to  be  described  follows: 
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Equipment  Configuration 


Processor(s)  including  number  of  each  on-line. 

Storage  media  (estimated  quantity  of  core,  drum,  disk,  and 
tape  storage). 

Input  devices  including  number  of  each  on-line. 

Output  devices  including  number  of  each  on-line. 
Communications  net  including  line  speeds. 


Equipment  requirements  will  be  related  to  the  requirements  stated  in 
paragraph  3. 1  of  the  PFD.  Changes  in  equipment  requirements  which  have 
occurred  since  the  publication  of  the  PFD  as  a  result  of  the  on-going 
analysis  and  design  will  be  explicitly  identified  and  the  reasons  for  the 
changes  will  be  stated.  Changes  in  the  equipment  configuration  of  the  user 
since  the  publication  of  the  PFD  will  be  discussed  in  regard  to  the  effects 
on  the  subsystem.  The  descriptions  of  identified  changes  wiljlj  include 
impacts  on  the  current  equipment  configuration  including  additions  and 
modifications  to  currently  available  equipments  as  well  as  changes  to  the 
operational  time  requirements  to  be  imposed  on  the  equipment. 


3. 2  Software  Environment.  Paragraph  3.  2  shall  provide  a  description  of 
the  subsystem  software  environment.  There  shall  be  included  the  correct 
nomenclature  and  documentation  references  of  each  software  system, 
subsystem,  and  program  with  which  the  subsystem  will  interact.  These 
will  include  functional  and  support  software.  Test  software  may  be 
included  at  the  discretion  of  the  Project  Leader.  Software  utilized  by  the 
System  will  be  related  to  the  requirements  stated  in  paragraph  3.2  of  the 
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PFD.  Changes  in  the  software  environment  which  have  occurred  since 
the  publication  of  the  PFD  will  be  explicitly  identified  and  the  reasons  for 
the  changes  will  be  stated.  The  descriptions  of  identified  changes  will 
include  impacts  on  the  currently  available  software  including  additions 
and  modifications  necessary  to  adapt  the  existing  software  packages  to  the 
project  requirements. 

3.3  Operational  Impacts.  Paragraph  3.3  shall  discuss  that  portion  of 
paragraph  2.3.2  of  the  PFD  which  relates  to  the  subject  subsystem. 

Changes  in  operational  impacts  related  to  the  subject  subsystem  which 
have  occurred  since  the  publication  of  the  PFD  will  be  identified  and  the 
reasons  for  the  changes  will  be  stated.  This  paragraph  will  include  changes 
to  such  items  as  data  sources,  quantity  and  type  of  data  to  be  provided, 
reporting  interval,  method  of  reporting,  and  recommended  methods  for 
providing  data. 

3.4  Organizational  Impacts.  Paragraph  3.4  shall  discuss  that  portion  of 
paragraph  2.3.  2  of  the  PFD  which  relates  to  the  subject  subsystem. 

Changes  in  Impacts  related  to  the  subject  subsystem  which  have  occurred 
since  the  publication  of  the  PFD  will  be  identified  and  the  reasons  for  the  . 
changes  will  be  stated.  This  paragraph  will  include  changes  to  such  items 
as  modifications  in  positional  functions  necessary  to  implement  the  new 
system,  manpower  to  maintain  the  database,  manpower  to  operate  and 
maintain  the  programs,  and  manpower  to  effectively  use  the  capability. 


NAVCOSSACT 

STANDARDS 


SUBJECT 

SUBSYSTEM 

SPECIFICATION 


3.  5  Subsystem  Interfaces.  Paragraph  3.5  shall  provide  a  description 
of  the  interfaces  with  other  systems  including  systems  of  other  operation¬ 
al  functions  and  other  commands  as  well  as  interfaces  with  other  internal 
subsystems.  For  each  interface,  the  following  shall  be  specified: 

Description  of  operational  implications  of  transfer  including 
security. 

Data  transfer  requirements  to  and  from  the  subject  subsystem. 

Current  formats  of  interchanged  data. 

Type  of  interface  such  as  manual  or  automatic. 

Interface  procedures. 

Interface  equipment. 

The  individual  interfaces  will  be  related  to  that  portion  of  paragraph  3.  3 
of  the  PFD  which  relates  to  the  subject  subsystem.  Although  the  interface 
descriptions  may  be  refined  and  more  detailed  as  a  result  of  the  on-going 
analysis  and  design,  they  must  be  directly  relatable  to  the  interfaces 
enumerated  in  the  PFD.  Changes  in  interfaces  which  have  occurred  since 
the  publication  of  the  PFD  will  be  explicitly  identified  and  the  reasons  for 
the  changes  will  be  stated.  Interface  changes  effecting  changes  in  scope 
of  the  system  effort  must  be  submitted  as  changes  to  the  PFD  in  accord¬ 
ance  with  ndard  30-20. 


3.  6  Timing.  This  paragraph  shall  provide  a  description  of  the  timing 
requirements  placed  on  the  subsystem,  if  they  are  available.  The 
following  timing  requirements  may  be  considered. 
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Throughput  time. 

Response  time  of  major  subsystem  functions. 

Cyclical  and  temporal  relations  of  functions. 

Priorities  imposed  by  types  of  inputs  and  changes  in  modes 
of  operation. 

Response  time  to  queries,  to  threshold  values,  to  parameterized 
cycles,  and  to  update  of  data  files. 

Timing  requirements  for  the  range  of  traffic  load  under  varying 
operating  conditions. 

Interleaving  requirements  for  sequencing  and  interleaving  pro¬ 
grams  and  systems  including  the  requirements  for  inter¬ 
rupting  a  program’s  operation  without  loss  of  data. 

The  individual  items  described  above  will  be  related  to  paragraph  3.4  of 
the  PFD.  Changes  in  timing  requirements  which  have  occurred  since  the 
publication  of  the  PFD  will  be  explicitly  identified  and  reasons  for  the 
changes  will  be  stated. 

3. 7  Accuracy.  Paragraph  3.7  shall  provide  a  description  of  accuracy 
requirements  imposed  on  the  subsystem.  Each  type  of  system  must 
consider  the  following  items  which  will  be  expressed  in  user  terms: 


Accuracy  requirements  of  numerical  input  and  output  data. 
Accuracy  requirements  of  mathematical  calculations. 
Logical  and  legal  accuracy  of  alphanumeric  data. 

Accuracy  of  transmitted  data. 
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The  Individual  items  described  above  will  be  related  to  paragraph  3.5 
of  the  PFD.  Changes  in  accuracy  requirements  from  those  stated  in  the 
PFD  will  be  explicitly  identified  and  the  reasons  for  the  changes  will  be 
stated. 

3.8  Security.  Paragraph  3. 8  shall  describe  the  classified  elements  of 
the  subsystem  including  inputs,  outputs,  or  data  base. 

The  elements  described  above  will  be  related  to  paragraph  3. 6  of  the  PFD. 
Changes  in  security  requirements  which  have  occurred  since  the  publica¬ 
tion  of  the  PFD  will  be  identified  and  reasons  for  the  changes  will  be 
stated. 

3.9  Controls.  Paragraph  3. 9  shall  provide  a  presentation  of  over-all 
subsystem  controls.  Included  in  this  paragraph  will  be  items  such  as 
record  counts,  accumulated  counts,  batch  controls,  etc.  If  no  specific 
controls  are  to  be  established  at  the  subsystem  level,  this  will  be  so 
stated. 

3. 10  Flexibility.  Paragraph  3. 10  shall  provide  a  description  of  the 
subsystem  flexibility,  i.  e. ,  ease  of  adapting  to  changing  requirements, 
ft  will  include  anticipated  operational  changes,  interaction  with  new  or 
improved  systems,  and  cyclic  updating  of  the  subsystem.  Identified  will 
be  those  elements  and  procedures  that  will  be  subject  to  change.  This 
paragraph  is  applicable  to  all  types  of  systems. 
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4.  DESIGN  DATA 


4. 1  Program  Descriptions 


4.1.1  Program  Description.  Paragraphs  4. 1. 1,  4. 1. 2, — 4.  l.nshall 
provide  descriptions  of  programs  in  the  subsystem;  each  program  will  be 
described  in  succeeding  paragraphs.  A  program  description  will  include 
functions  (related  to  paragraph  2. 3),  inputs,  outputs,  and  data  base. 
Descriptions  for  all  of  the  various  types  of  programs  (functional  or 
support)  will  include  the  information  below  if  applicable. 


Inputs  -  each  input  will  be  described  as  follows: 


Title 

Format 

Number  of  items 

Means  of  entry  and  input  initiation  procedures;  e.g. , 
typewriter,  card,  tape,  sensor,  internal; 

Expected  volume  and  frequency  including  special  handling 
for  high  density  periods  such  as  queuing  and  priority  handling. 
Priority;  e.g.,  routine,  emergency. 

Sources,  form  at  source,  and  disposition  of  source  document. 
Security  classification  of  input  and  individual  items. 
Requirements  for  timeliness. 
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Outputs  -  each  output  will  be  described  as  follows: 

a.  Title 

b.  Format  to  include  headings,  line  spacing,  arrangement, 
totals,  etc. 

c.  Number  of  items 

d.  Preprinted  form  requirements. 

e.  Means  of  display;  e.g.,  typewriter,  printer,  projector, 
CRT,  alarm  type,  internal. 

f .  Expected  volume  and  frequency  including  special  handling 
for  high  density  periods  such  as  queuing  and  priority 
handling. 

g.  Prioirty;  e.  g. ,  routine,  emergency. 

h.  Timing  requirements;  e.g. ,  response  time. 

i.  User  recipients  and  use  of  displays  such  as  notification, 
trends,  or  briefings. 

j.  Security  classification  of  output  and  individual  items. 


Data  Base  -  each  datafile,  table  or  dictionary  will  be  described  as 
follows: 


a.  Title 


b.  Description  of  content 

c.  Number  of  records  or  entries 

d.  Storage  to  include  type  of  storage  and  address 

e.  Classification 

f.  Data  retention  requirements 
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4.2  Logical  Flow.  Paragraph  4. 2  shall  describe  the  logical  flow  of  the 
subsystem.  Logical  flow  will  be  presented  primarily  in  the  form  of 
In/Out  Flow  Charts  and  a  System  Logic  Chart  (for  the  subsystem)  prepared 
in  accordance  with  Standard  50-15.  Charts  will  be  in  sufficient  detail  to 
permit  program  design.  A  narrative  presentation,  when  appropriate, 
will  be  used  to  supplement  the  flow  charts. 

Flow  charts  will  provide  an  integrated  presentation  of  the  subsystem 
dynamics  and  will  provide  entrances  and  exits  as  well  as  interfaces  with 
other  programs.  Flow  charts  will  effectively  represent  all  modes  of 
operations,  priorities,  cycles,  and  special  handling.  The  charts  will 
show  data  flow  from  input,  through  the  subsystem  to  the  generation  of 
output. 
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APPENDIX 

SYSTEM  ABBREVIATIONS,  MNEMONICS,  AND  TERMS 


The  /Appendix  will  provide  the  definitions  of  terms  or  phrase  definitions 
which  carry  connotations  unique  to  this  particular  system  or  which  are 
not  sufficiently  standard  as  to  be  adequately  defined  in  standard 
dictionaries.  Item  names  and  location  tags  uitiiized  by  the  various 
programs  of  the  system  will  specifically  not  be  included  in  the  Appendix; 
these  are  to  be  completely  defined  in  the  body  of  the  specification.  The 
Appendix  is  intended  primarily  to  provide  definitions  of  terms  to  be 
found  in  the  documentation  writing  and  not  of  terms  unique  to  specific 
programs. 
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1.  GENERAL  SPECIFICATION  INFORMATION 

1. 1  Purpose  of  Specification.  This  documentation  specification  provides 
guidance  for  the  preparation  of  the  Data  Requirements  Document  (DRD). 

A  Data  Requirements  Document  will  be  prepared  at  the  discretion  of  the 
Project  Leader  when  a  substantial  data  collection  effort  is  required. 

1.2  Scope  of  Specification 

1. 2. 1  General.  Each  Data  Requirements  Document  shall  include  the  in¬ 
formation  starting  with  Section  1  GENERAL  below  in  the  order  presented 
in  this  specification  and  under  the  paragraph  titles  specified.  All  para¬ 
graphs  are  not  applicable  to  every  system  for  which  a  Data  Requirements 
Document  is  written  and  portions  not  pertinent  to  a  particular  system  may 
be  designated  as  not  applicable  by  the  Project  Leader.  In  general,  utility 
and  support  systems  do  not  require  user  inputs  or  usage  of  defined  data 
elements  and,  therefore,  do  not  require  a  Data  Requirements  Document. 

1.2.  2  Interface  with  NAVCOSSACT  Data  Element  Library.  The  Data 
Requirements  Document  effort  is  a  complementary  effort  to  the  Data 
Element  Library  collection.  In  general,  the  same  basic  data  element 
information  is  required  and  compatibility  of  the  Data  Element  Library  and 
the  Data  Base  Requirements  is  necessary. 

1.2.3  Procedures  for  Data  Element  Collection.  NAVCOSSACT  Reports 
196  and  197  provide  the  recommended  procedures  for  Data  Element  Collec¬ 
tion  zriu  will  be  used  as  the  guideline  documents. 
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1.2.4  Utilization  of  Data  Element  Library  and  Staff.  The  existing  Data 

Element  Library  is  the  source  of  standard  data  element  information.  The 
use  of  this  Library  will  facilitate  standardization  of  data  elements  and 
enhance  NAVCOSSACT 's  systems  capability.  NAVCOSSACT  Data  Element 
Library  personnel  will  be  available  to  provide  assistance  in  preparation 
of  the  Data  Requirements  Document.  -  - 

I  l 

H 

1.2.5  Reader  Orientation.  The  Data  Requirements  Document  is  a  techni¬ 
cal  ADP  document  prepared  for  both  systems  and  user  personnel.  It  is  to 
be  as  detailed  as  possible  concerning  the  definition  of  inputs  required  of  the 
user,  the  procedures  to  be  followed  to  provide  this  input  to  the  system,  and 
the  description  of  expected  output  data  along  with  the  systems  data  limita¬ 
tions. 

t 

2.  CONTENT  OF  DATA  REQUIREMENTS  DOCUMENT 

The  content  of  the  Data  Requirements  Document  shall  be  in  accordance 

with  the  format  on  the  following  pages.  I  , 
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1.  GENERAL 

1.1  Purpose  and  Scope  of  Data  Requirements  Document.  Paragraph  1  1 
shall  describe  the  purpose  of  the  Data  Requirements  Document  f'  r  the 
specific  system  under  development.  The  description  will  be  in  ri  rdance 
with  the  following  NAVCOSSACT  objectives  for  preparing  a  Data  Requite 
ments  Document: 

a.  Specify  data  elements  which  the  system  must  handle 

b.  Communicate  data  requirements  to  the  user  ft  r  supp*  rt  it  *ne 
data  collection  activity. 

A  description  of  the  type  cf  system  being  documented  shall  be  giver  i  e  . , 
support,  utility,  operations,  etc.  This  shall  include  a  statement  •  f  »he 
type  of  data  required  by  the  system.  This  paragraph  shall  s»ate  in  gei  eral 
terms  the  user  support  necessary  to  furnish  the  required  system  data  t\  r 
the  Data  Requirements  Dt  cument. 

1.2  Project  Reference.  Paragraph  1.2  shall  state  the  pri  ie«.t  ti»le  and 
number  and  provide  a  brief  statement  of  the  pri  ject  tbje  fives.  This  para¬ 
graph  shall  also  identify  the  project  sponsor  and  user(s).  A  statement  ,  f 
the  relationship  of  this  project  to  other  projects  shall  be  giver..  Inluded 
will  be  all  those  projects  having  interfaces  with  this  system  and  all  rt  si 
systems  of  historical  significance  for  this  pr<  ject 
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1.3  Applicable  Documents.  Paragraph  1.3  shall  provide  a  list  of  appli¬ 
cable  documents  by  number  and  title.  This  paragraph  will  include  at 
least  the  following  when  applicable: 

Project  Request 

Feasibility  Study  Documentation  .  _  _ _ 

Preliminary  Functional  Description 

1.4  Modification  of  Data  Requirements.  Paragraph  1.4  shall  describe  the 
procedures  for  implementing  and  documenting  changes  to  the  system  data 
requirements,  if  applicable. 


2.  DATA  DESCRIPTION 

The  data  described  in  this  section  shall  be  separated  into  two  categories; 
static  data  and  dynamic  data.  Static  data  is  defined  as  that  data  which 
is  used  mainly  for  reference  during  system  operation  and  is  usually  gener¬ 
ated  or  updated  in  widely  separated  time  frames  independent  of  normal 
system  runs.  Dynamic  data  includes  all  data  which  is  intended  to  be 
updated  and  which  is  either  input  to  a  system  during  a  normal  run  or  out¬ 
put  by  the  system.  (Note:  At  NAVCOSSACT,  static  data  as  described 
above  is  frequently  referred  to  as  parametric  data  and  dynamic  data  as 
non-parametric  data.)  The  data  element  titles  listed  in  Sections  2. 1,  2.2, 
and  2.3  shall  have  titles  consistent  with  tffls  Appendix  of  this  document  and 
the  NAVCOSSACT  Data  Element  Library  to  facilitate  further  data  element 
information  reference. 
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2. 1  Logical  Organization  of  Static  System  Data.  This  paragraph  shall 
provide  a  listing  of  those  static  data  elements  used  by  the  system  for 
either  parametric  control  or  reference  purpose.  The  data  elements  will 
be  arranged  alphabetically,  by  title.  A  further  breakdown  of  data  elements 
according  to  functions,  subjects,  or  other  categorizations  which  are  most 
relevant  to  their  usage  may  be  made  at  the  discretion  of  the  Project  Leader. 
However,  within  each  category  the  data  element  titles  will  be  arranged 
alphabetically,  by  title. 


2.2  Logical  Organization  of  Dynamic  Input  Data.  This  paragraph  shall 
provide  a  listing  of  those  dynamic  input  data  elements  which  constitute  the 
data  that-is  intended  to  be  updated  by  a  normal  system  run  or  during  on-line 
operation.  The  data  elements  will  be  arranged  alphabetically,  by  title. 

A  further  breakdown  of  data  elements  according  to  functions,  subjects,  or 
other  categorizations  which  are  most  relevant  to  their  usage  may  be  made 
at  the  discretion  of  the  Project  Leader.  However,  within  each  category 
the  data  element  titles  will  be  arranged  alphabetically,  bj* title. 

2.3  Logical  Organization  of  Dynamic  Output  Data.  This  paragraph  shall 
provide  a  listing  of  those  dynamic  output  data  elements  which  constitute  the 
data  that  is  intended  to  be  updated  and  output  by  a  normal  system  run  or 
during  on-line  operation.  The  data  elements  will  be  arranged  alphabetically, 
by  title.  A  further  breakdown  of  data  elements  according  to  functions, 

i 

subjects,  or  other  categorizations  which  are  most  relevant  to  their  usage 
mav  be  made  at  the  discretion  of  the  Project  Leader.  However,  within  each 
category  the  data  element  titles  will  be  arranged  alphabetically,  by  title. 
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2.4  Internally  Generated  Data.  Paragraph  2.4  shall  provide  an  alphabet¬ 
ical  listing  of  internally  generated  data  which  is  of  interest  to  the  user. 

The  selection  of  elements  to  be  included  in  this  paragraph  will  be  at  the 
discretion  of  the  Project  Leader  since  they  will  only  be  of  informational 
value  to  the  user  and  will  require  no  action  by  the  user. 

2.  5  System  Data  Constraints.  Paragraph  2.  5  shall  state  all  the  known  or 

anticipated  system  data  constraints  at  this  phase  of  the  system’s  develops- 

4  * 

ment.  This  information  will  be  a  general  indicahion  of  the  limits  of  this 
system  with  regard  to  future  expansion  or  utilization.  This  shall  be  a 
statement  of  the  maximum  size  and  the  maximum  number  of  files,  records, 
and  elements.  Emphasis  shall  be  placed  on  limits  which  could  prove 
critical  in  future  systems  development. 

3.  USER  SUPPORT  REQUIRED  FOR  DATA  COLLECTION 

All  of  the  data  elements  required  for  the  system  will  be  defined  in  Para¬ 
graphs  2. 1,  2. 2,  and  2.3.  Section  3  will  describe  the  data  collection 
support  from  the  user  required  to  establish  the  data  values  necessary  to 
support  the  particular  system. 

3.1  Data  Collection  Requirement.  Paragraph  3. 1  shall  describe  the  in¬ 
formation  required  for  establishing  the  system  data  values  of  each  element. 
It  shall  state  that  each  data  element  will  be,  as  a  minimum,  described  in 
accordance  with  the  information  required  for  the  Data  Element  Library. 

In  audition,  me  project  ijyauer  may  require  the  following  supplementary 
information: 


■H  i 
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a.  Input  Source(s)  of  the  Data  Element.  This  item  names  the  source(s) 
from  which  the  data  element  will  be  fed  into  the  system.  The 
source,  or  origin,  of  the  data,  will  be  an  operator,  station,  organ¬ 
isation  unit,  etc.  or  groups  thereof;  not  the  hardware  device  used 
for  entering  the  data.  An  exception  can  be  made  in  the  case  of 
automatic  sensor  devices,  but  in  this  case,  the  device  should  be 
linked  to  another  data  element  set  such  as  vehicle  carrying  the 
device,  organization  responsible  for  its  use  or  maintenance,  geo¬ 
graphic  location,  etc. 

b.  Input  Medium.  This  item  names  the  hardware  device  used  for 
entering  the  data  into  the  system.  In  those  cases  where  only  cer¬ 
tain  special  stations  are  the  legal  entry  points,  those  discrete 
devices  shall  be  specified. 

c.  Recipients.  The  item  specifies  those  users  (other  than  the  origina- 

'  *■* 

tor)  who  should  be  cognizant  of  the  data.  This  applies  in  the  follow¬ 
ing  cases: 

Data  elements  input  to  the  system,  processed  by  it,  and  output 
by  it  essentially  unchanged. 

Data  elements  generated  by  a  program  and  output  to  the  user. 

Data  elements  input  to  the  system  but  which  do  not  get  output 
by  it.  In  this  case,  the  program  would  substitute  for  the 
user  as  the  recipient. 


Critical  Value.  Many  data  elements  that  have  a  range  of  values 
will  have  one  value  that  is  particularly  significant  to  the  user. 
This  may  be  a  breakpoint,  a  minimum  stock  level,  a  critical  wind 
velocity,  etc.  When  applicable,  the  critical  value  and  its  signifi¬ 
cance  to  the  user  should  be  included  in  the  definition. 
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e.  Increment  of  Measurement.  If  the  successive  steps  on  the  measure¬ 
ment  scale  (the  gauge)  are  not  equal  to  ’’one”  on  the  units  of 
measurement,  then  the  increment  used  shall  be  specified.  For 
example,  a  data  element  representing  pounds  of  pressure  per 
square  inch  (the  unit  of  measurement)  may  be  incremented  at  pound, 
half-pound,  or  ten-pound  Intervals. 

f.  Conversion  Factors.  Measured  quantities  that  must  go  through 
analog  and  digital  conversion  processes  shall  have  the  conversion 
factors  specified. 

g.  Output  Form/Device.  Output  data  elements  may  be  presented  to 
the  user  symbolically,  graphically,  or  audibly.  The  definition 
should  specify  whether  the  user  will  receive  this  data  element  as 
part  of  a  hard-copy  printout,  a  character  in  a  CRT  display,  a  line 
on  a  drawing,  a  colored  light,  an  alarm  bell,  etc. 

h>  Expansion  Factors.  For  systems  that  are  expected  to  undergo 
future  expansion,  it  is  prudent  to  include  an  expansion  factor  to  be 
added  to  the  maximum  number  of  entries  of  this  data  element.  For 
instance,  if  the  maximum  number  of  input  devices  is  now  12,  but 
is  expected  to  be  96  three  years  from  now,  the  800%  expansion 
factor  should  be  specified. 

i.  Frequency  of  Update.  Data  elements  that  are  input  to  the  system  or 
that  are  expected  to  be  modified  by  the  system  on  a  periodic  basis 
should  have  the  frequency  of  update  specified. 


3. 2  Scope  of  Data  Collection.  Paragraph  3.  2  shall  specify  the  specific 
information  to  be  collected  by  the  user.  These  shall  be  logically  grouped 
and  presented  in  a  manner  which  will  enable  the  user  to  make  an  effective 
response. 
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3.3  Recommended  Scource  of  Input  Data.  Paragraph  3.3  shall  delineate 
the  source(s)  of  input  data.  Recommendation  as  to  who  shall  be  responsible 
for  providing  specific  data  inputs  shall  be  stated  here.  This  shall  include 
recommendations  regarding  the  establishment  of  a  user  input  reporting 
organization  if  required.  Those  data  inputs  dependent  on  interfacing  sys¬ 
tems,  unrelated  agencies,  or  specific  documents  should  be  stated  and  the 
source  defined. 


3.4  Data  Collection  and  Transfer  Procedures.  Specific  instructions  for 
data  collection  procedures  shall  be  given  in  Paragraph  3.4.  These  instruc¬ 
tions  shall  include  detailed  formats  where  applicable.  Communications 
media  and  timing  of  inputs  shall  be  stated  also. 
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The  Appendix  of  the  Data  Requirements  Document  shall  be  in  alphabetical 
(by  title)  listing  of  all  the  data  elements  of  this  system.  Each  element  shall 
be  defined  in  accordance  with  the  NAVCOSSACT  Data  Element  Library 
standard  and  shall  follow  the  format  specified  in  NAVCOSSACT  Report  196. 
The  Appendix  shall  include  appropriate  cross  referencing  to  the  listings  in 
Sections  2.1,  2.2,  and  2.3. 
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1. 1  Purpose  of  Specification.  This  documentation  specification  provides 
guidance  for  the  preparation  of  Program  Specifications.  A  Program  Speci¬ 
fication  is  required  for  each  program  in  every  system  developed  by 
NAVCOSSACT. 


1.2  Scope  of  Specification 

1.2.1  General.  A  Program  Specification  may  include  all  or  portions  of 
the-  information  starting  with  Section  1  GENERAL  below  in  the  order  pre¬ 
sented  in  this  specification  and  under  the  paragraph  titles  specified.  All 
paragraphs  are  not  applicable  for  every  Program  Specification  written 
since  the  document  may  be  used  to  provide  general  guidance  to  the  pro¬ 
grammer  to  permit  program  development,  or  it  may  be  used  to  provide  all 
the  details  necessary  to  allow  coding  from  the  contents  of  the  document. 
Portions  not  pertinent  to  a  particular  program  may  be  designated  not 
applicable  by  the  Project  Leader.  The  Program  Specification  may  present 
modifications  from  the  Preliminary  Functional  Description  (PFD),  and  it 
should  be  noted  that  any  modification  to  the  scope  of  the  system  effort  must 
be  submitted  as  changes  to  the  PFD  in  accordance  with  Standard  30-20. 

i.  2. 2  Reader  Orientation.  The  Program  Specification  is  a  technical  ADP 
document.  The  amount  of  detail  to  be  included  is  dependent  upon  the  use 
<o  be  made  of  the  document  within  the  particular  project  for  which  it  is 
prepared.  It  may  be  prepared  by  the  Project  Leader,  systems  analyst,  or 
programmer  to  guide  program  development.  The  Program  Specification 
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will  provide  some  redundancy  with  the  PFD  and  the  related  Subsystem 
Specification  when  one  is  prepared;  however,  it  is  anticipated  that  the 
Program  Specification  will  present  more  detailed  data  as  a  result  of  the 
detailed  program  design  effort.  Furthermore,  a  Program  Specification 
will  only  consider  those  segments  of  a  PFD  or  Subsystem  Specification  that 
are  applicable  to  the  particular  program. 


2.  CONTENT  OF  PROGRAM  SPECIFICATION 

The  content  of  the  Program  Specification  shall  be  in  accordance  with  the 
format  on  the  following  pages. 
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1.  GENERAL 

1. 1  Purpose  of  Program  Specification.  Paragraph  1. 1  shall  describe  the 
purpose  of  the  Program  Specification.  The  description  will  be  in  accordance 
with  the  following  NAVCOSSACT  objectives  for  the  preparation  of  a  Program 
Specification: 

a.  Describe  the  program  design  to  permit  program  production  by 
the  programmer/coder  with  sufficient  detailed  information  so  that 
the  design  ultimately  may  be  translated  into  instructions. 

b.  Provide  a  permanent  record  of  the  detailed  operation  of  the  pro¬ 
gram. 

1.2  Project  Reference.  Paragraph  1.2  shall  state  the  project  title  and 
number  and  provide  a  brief  summary  of  the  project  objectives.  This  para¬ 
graph  will  also  identify  the  project  sponsor  and  user(s). 

L.3  Applicable  Documents.  Paragraph  1.3  shall  provide  a  list  of  applicable 
iocuments  by  number  and  title.  This  paragraph  will  include  at  least  the 
following  when  applicable: 


Preliminary  Functional  Description 
Associated  Subsystem  Specification 
Related  Program  Specifications 
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PROGRAM 
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2.  SCOPE 

2. 1  Program  Description.  Paragraph  2. 1  shall  provide  a  general  des¬ 
cription  of  the  program  to  establish  a  frame  of  reference  for  the  remainder 
of  the  document.  The  system  description  in  paragraph  2. 1  of  the  PFD  may 
be  referenced.  Also  referenced  will  be  the  parallel  programs  and  their 
documentation  as  required  to  enhance  the  general  description  of  the  pro¬ 
gram.  If  the  program  is  common  to  more  than  one  subsystem  or  system, 
appropriate  references  will  be  made  to  the  applicable  Subsystem  Specifica¬ 
tions  and  PFD's. 

2.  2  Program  Functions.  Paragraph  2.2  shall  describe  the  program's 
functions.  These  shall  be  taken  directly  from  those  portions  of  the  sub¬ 
system  functions  (Paragraph  2.3  of  the  Subsystem  Specification)  or  the 
system  functions  (Paragraph  2.  3.  4  of  the  PFD)  which  apply  to  the  subject 
program.  The  functions  of  the  program  may  be  described  in  relation  to 
the  specific  requirements  they  satisfy  if  this  information  will  enhance  a 
description  of  the  functions.  The  specific  requirements  may  be  taken 
directly  from  the  subsystem  requirements  (Paragraph  2.2  of  the  Subsystem 
Specification)  or  system  requirements  (Paragraph  2.3.3  of  the  PFD)  which 
app  y  to  the  subject  program.  There  will  L  e  both  qualitative  and  quantita¬ 
tive  descriptions  of  how  the  program  satisfies  the  functions.  If  a  program 
docs  not  in  itself  satisfy  system  or  subsystem  functions,  but  is  used  in 
conjunction  with  other  programs  to  satisfy  system  or  subsystem  functions, 
this  fact  shall  be  noted  in  the  presentation  with  a  statement  showing  how  the 
aggregate  of  programs  completely  satisfies  the  functions.  Although  the 
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function  descriptions  may  be  refined  and  more  detailed  as  a  result  of  the 
on-going  analysis  and  design,  they  must  be  directly  related  to  the  subsystem 
or  system  functions  and  they  must  be  stated  in  such  a  manner  that  program 
environment  can  be  related  to  them. 

3.  ENVIRONMENT 

3. 1  Program  Requirements.  Paragraph  3. 1  shall  provide  a  description 
of  general  program  requirements,  e.g. ,  character  code  configuration 
(Baudot;  BCD,  Fieldata,  Hollerith;  etc),  fixed  or  floating  point  arithmetic, 
and  character  code  formats  (number  of  bits;  least  significant  bit  first  or 
last). 

3.2  Equipment  Environment.  Paragraph  3. 2  shall  present  descriptions 
of  the  equipment  used  by  the  subject  program  to  include  only  the  correct 
nomenclature,  special  features  not  implied  by  this  nomenclature,  and  the 
number  presently  available  of  each  type  of  equipment.  Equipment  require¬ 
ments  will  be  related  to  the  requirements  stated  in  paragraph  3. 1  of  the 
Subsystem  Specification  or  the  PFD.  Changes  in  equipment  requirements 
which  have  occurred  since  the  publication  of  the  next  higher  order  document 
will  be  identified  and  justified.  The  descriptions  of  identified  changes  will 
include  impacts  on  the  current  equipment  configuration  including  additions 
and  modifications  to  currently  available  equipment  as  well  as  changes  to 
the  operational  time  requirements  to  be  Imposed  on  the  equipment. 
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3.3  Software  Environment.  Paragraph  3.3  shall  provide  a  description 

of  the  program  software  environment.  There  shall  be  included  the  correct 
nomenclature  and  documentation  references  of  each  software  system,  sub¬ 
system,  and  program  with  which  the  program  will  interact.  These  will 
Include  operational  and  support  software.  Test  software  may  be  included 
at  the  discretion  of  the  Project  Leader.  In  addition,  there  will  be  a 
description  of  the  programming  language  to  be  used  by  the  program. 
Changes  in  the  software  environment  which  have  occurred  since  the  pub¬ 
lication  of  the  Subsystem  Specification  or  the  PFD  as  a  result  of  the  on¬ 
going  analysis  will  be  explicitly  identified  and  the  reasons  for  the  changes 
will  be  stated.  The  descriptions  of  identified  changes  will  include  impacts 
on  the  currently  available  software  including  additions  and  modifications 
necessary  to  adapt  the  existing  software  to  the  subject  program. 

3.4  Operational  Impacts.  Paragraph  3 . 4  shall  discuss  that  portion  of 
paragraph  3.3  of  the  Subsystem  Specification  or  of  paragraph  2.3.2  of  the 
PFD  which  applies  to  the  subject  program.  Changes  in  operational  impacts 
related  to  the  program  which  have  occurred  since  the  publication  of  the 
Subsystem  Specification  or  the  PFD  will  be  identified  and  the  reasons  for 
the  changes  will  be  stated.  This  paragraph  will  include  changes  to  such 
items  as  data  sources,  quantity  and  type  of  data  to  be  provided,  reporting 
interval,  method  of  reporting,  and  recommended  methods  for  providing 
data. 

3. 5  Organizational  Impacts.  Paragraph  3. 5  shall  discuss  that  portion  of 
paragraph  3.4  of  the  Subsystem  Specification  or  Paragraph  2.3.2  of  the 
PFD  which  applies  to  the  subject  program.  Changes  in  organizational 
impacts  related  to  the  program  which  have  occurred  since  the  publication 
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of  the  Subsystem  Specification  or  the  PFD  will  be  identified  and  the  reasons 
for  the  changes  will  be  stated.  This  paragraph  will  include  changes  to  such 
items  as  modifications  in  positional  functions  necessary  to  implement  the 
new  system,  manpower  to  maintain  the  data  base,  manpower  to  operate 
and  maintain  the  programs,  and  manpower  to  effectively  use  the  capability. 

3.6  Program  Interfaces.  Paragraph  3.6  shall  provide  a  description  of  the 
interfaces  with  other  programs  including  programs  of  other  operational 
functions  and  other  commands  as  well  as  interfaces  with  other  internal 
programs.  For  each  interface,  the  following  shall  be  specified: 

Description  of  operational  implications  of  transfer  including 
security. 

The  data  transfer  requirements  to  and  from  the  subject  program 
(data  content,  sequence,  tinning,  format,  volume,  and 
processing). 

Formats  of  interchanged  data. 

Data  conversion  requirements. 

Type  of  interface  such  as  manual  or  automatic. 

Interface  equipment. 

Interface  procedures. 

The  individual  interfaces  will  be  related  to  that  portion  of  paragraph  3.  5 
of  the  Subsystem  Specification  or  paragraph  3.3  of  the  PFD  which  relates 
to  the  subject  program.  Changes  in  interfaces  which  have  occurred  since 
the  publication  of  the  next  higher  order  document  will  be  explicitly  identified 
and  the  reasons  for  the  changes  will  be  stated. 
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3. 7  Timing.  This  paragraph  shall  provide  a  description  of  the  timing 
requirements  placed  on  the  program.  The  following  timing  requirements 
may  be  considered: 

Throughput  time. 

Response  time  of  major  program  functions. 

Cyclical  and  temporal  relations  of  functions  and  dataflows. 

Priorities  imposed  by  types  of  inputs  and  changes  in  modes  of 
operation. 

Response  time  to  queries,  to  threshold  values,  to  parameterized 
cycles,  and  to  update  of  datafiles. 

Timing  requirements  for  the  range  of  traffic  load  under  varying 
operating  conditions. 

Interleaving  requirements  for  sequencing  and  interleaving  pro¬ 
grams  and  systems  including  the  requirements  for  interrupt¬ 
ing  a  program’s  operation  without  loss  of  data. 

I/O  transfer  time  required  -  disk,  drum,  tape. 

Internal  processing  time. 


The  individual  items  described  above  will  be  related  to  that  portion  of 
paragraph  3.6  of  the  Subsystem  Specification  or  paragraph  3.4  of  the  PFD 
which  relates  to  the  subject  program.  Changes  in  timing  requirements 
from  the  next  higher  order  document  will  be  explicitly  identified  and 
justified. 

3. 8  Accuracy.  Paragraph  C.  8  shall  provide  a  description  of  accuracy 
requirements  placed  upon  the  program.  Each  type  of  program  must  con¬ 
sider  the  following  items: 
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Accuracy  requirements  of  numerical  input  and  output  data,  j 
Accuracy  requirements  of  mathematical  calculations.  / 
Logical  and  legal  accuracy  of  alphanumeric  data. 

Accuracy  of  transmitted  data. 

This  paragraph  will  designate  techniques  such  as  parity  transmission  to  be 
utilized  to  insure  meeting  the  specified  accuracy  requirements. 

The  items  described  above  will  be  related  to  that  portion  of  paragraph  3.  7 
of  the  Subsystem  Specification  or  paragraph  3. 5  of  the  PFD  which  relates 
to  the  ruhjoct  program.  Changes  in  accuracy  requirements  from  the  next 

t 

higher  order  document  will  be  explicitly  identified  and  the  reasons  for  the 
changes  will  be  stated. 

I  ■ 
l 

3. 9  Storage.  Paragraph  3.  9  shall  provide  a  description  of  storage  require¬ 
ments  for  the  program.  Included  shall  be  internal  storage  requirements 
I  and  use  of  homogeneous  core  and  auxiliary  storage  -  tape,  disk,  drum  - 
with  the  estimated  quantity  of  storage  required  for  each.  Each  type  of  pro¬ 
gram  must  give  consideration  to  the  following  types  of  information  for  the 
various  storage  media: 


Core  storage;  no.  of  words/core  bank;  no.  of  banks. 

Drum  storage;  no.  of  words/field;  no.  of  fields/drum;  no.  of 
drum  assemblies. 

Disk  storage;  no.  of  words/zone;  no.  of  zones/disk;  no.  of 
disks/disk  unit;  no.  of  disk  units. 

Tape  storage;  no.  of  adapters;  no.  of  tape  drives/adapter;  no. 
of  tapes. 
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In  addition,  the  machine  storage  will  be  further  allocated  into  permanent 
and  temporary  areas. 


3. 10  Security.  Paragraph  3. 10  shall  describe  the  classified  elements  of 
the  program  including  inputs,  outputs,  and  data  base.  The  individual 
elements  described  above  will  be  related  to  paragraph  3.  8  of  the  Subsystem 
Specification  or  paragraph  3. 6  of  the  PFD  and  any  changes  will  be  described 
and  justified. 

3.11  Controls.  Paragraph  3.11  shall  provide  a  presentation  of  any  pro¬ 
gram  controls.  Included  in  this  paragraph  will  be  items  such  as  record 
counts,  accumulated  counts,  batch  controls,  etc.  K  no  specific  controls 
are  to  be  established  at  the  program  level,  this  will  be  so  stated.  The 
controls  described  above  will  be  related  to  that  portion  of  paragraph  3.9 
of  the  Subsystem  Specification  which  relates  to  the  subject  program. 


3. 12  Flexibility.  Paragraph  3. 12  shall  provide  a  description  of  the  pro¬ 
gram  flexibility,  i.  e. ,  ease  of  adapting  to  changing  requirements.  It  will 
include  anticipated  operational  changes,  interaction  with  new  or  improved 
programs,  and  cyclic  updating  of  the  program.  Defined  also  will  be  those 
elements  and  procedures  that  will  be  subject  to  change.  This  paragraph 
will  be  related  to  the  portions  of  paragraph  3. 10  of  the  Subsystem  Specifica¬ 
tion  that  are  applicable  to  the  subject  program. 

4.  DESIGN  DATA 

4. 1  Terminal  Procedures.  Paragraph  4. 1  shall  provide  a  description  of 
the  system  terminal  procedures.  There  will  be  a  description  of  the  load, 
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start,  stop,  and  restart  procedures.  The  special  program  requirements 
necessary  for  the  implementation  of  these  terminal  functions  shall  be 
delineated.  There  shall  also  be  defined  the  communication  requirements 
for  all  programs  with  the  executive  or  control  program.  In  addition, 
Program  Specifications  for  executive  or  control  type  support  programs 
for  multiprocessor  systems  will  include  processor  switchover  procedures. 


4.2  Inputs.  Paragraph  4.2  shall  provide  a  detailed  description  of  all 
program  inputs.  There  shall  be  a  description  of  each  type  of  input  appli¬ 
cable  to  the  program.  Each  input  shall  be  categorized  by  type  and  de¬ 
scribed  in  detail  to  include  the  following  as  applicable: 


a. 

b. 

c. 

d. 


e. 

f. 

g- 

h. 

i. 


Title  and  tag. 

Format. 

Number  of  items.  , 

Description  of  each  itipni  to  include  number  and  type  of  characters 
(numeric,  alpha,  decimal,  signed,  unsigned),  range  of  values, 
accuracy  requirement.! 

Means  of  entry  and  initiation  procedures;  e.g.,  typewriter,  card, 
tape,  sensor,  internal. 

Length  of  input  including  special  handling  requirements  due  to 
variations  in  length. 

Expected  volume  and  frequency  including  special  handling  for 
high  density  periods  such  as  queuing  and  priority  handling. 
Priority;  e.  g. ,  routine,  emergency. 

Sources,  form  at  source,  and  disposition  of  source  document. 


j.  Disposition  other  than  processing  such  as  logging,  retention 

in  input  form,  hard  copy  reproduction  of  input,  storage  location, 
and  custodian. 

k.  Security  classification  of  input. 

l.  Flexibility  such  as  capability  of  omitting  and  adding  items. 

m.  Requirements  for  » imo!in«\ss. 

n.  Throughput  tim« 

o.  Special  handling  such  as  specification  of  special  control  cards. 

This  paragraph  shall  include  examples  of  prepared  inputs  and  user  inter¬ 
faces  such  as  input  creation  sheets  and  message  forms. 

4.  3  Outputs.  Paragraph  4.  3  shall  provide  a  detailed  description  of  all 
program  outputs.  There  shall  be  included  a  description  of  each  type  of 
output  applicable  to  the  program.  Each  output  shall  be  categorized  by 
type  and  described  in  detail  to  include  the  following  as  applicable: 

a.  Title  and  tag. 

b.  Format  to  include  headings,  line  spacing,  arrangement,  totals,  etc. 

c.  Number  of  items. 

d.  Description  of  each  item  to  include  number  and  type  of  characters 
(alpha,  numeric,  symbol,  etc.),  range  of  values,  accuracy  re¬ 
quirement,  supporting  background  information  to  be  presented 
(e.g.  ,  maps) 

c  Data  selection  criteria  will  be  presented  to  establish  the  basis  for 
selecting  information  for  display;  e.g. ,  selection  for  a  mainte¬ 
nance  report  may  be  on  the  basis  of  active  records  in  a  file  of 
aircraft  type  and  aircraft  usage. 
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f.  Description  of  plots  or  graphic  displays  will  include  the  coordin¬ 
ates  to  be  used,  symbols  to  be  used,  type  of  graphic  technique 
(i.e.,  point  or  continuous),  number  of  curves  per  sheet,  etc. 

g.  Preprinted  form  requirements. 

h-  Means  of  display,  e.g. ,  typewriter,  printer,  projector,  CF.T, 
alarm  type,  internal. 

i.  Length  cf  output  including  special  handling  requirement  due  to 
variations  in  length. 

j.  Expected  volume  and  frequency  including  special  handling  for 
high  density  periods  such  as  queuing  and  priority  handling. 

k.  Priority;  e.  g. ,  routine,  emergency. 

•1.  Timing  requirements;  e.  g. ,  response  time. 

m.  User  recipients  and  use  of  displays  such  as  notification,  trends, 
or  briefings. 

n.  Disposition  including  logging,  film  and  hard  copy  printout  repro¬ 
duction  and  storage,  numbers  of  copies  required  for  distribution, 

,  place  of  storage,  person  responsible  for  permanent  copy,  re¬ 

tention  period,  and  special  handling  required  because  of  bulk, 
classification,  timing. 

o.  Security  c  ’  ass  if  ic  alien  of  c"fprt. 

p.  Throughput  time. 

q.  Explanation  of  symbols. 

r.  Conditional  and/or  status  indicators  (code  and  condition  definition). 

Included  in  this  paragraph  shall  be  examples  of  program  outputs. 
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4.4  Data  Environment.  Paragraph  4.4  shall  provide  a  description  of  the 
data  environment  of  the  program.  There  shall  be  included  descriptions 
of  the  files,  tables,  dictionaries,  program  inter-relationship  with  the 
tables,  storage  allocation,  intermediate  data  structures,  and  data  retention 
requirements.  A  compool  structure  may  be  defined  here  if  the  program  is 
compool  oriented.  This  paragraph  does  not  replace  the  requirement  for 
the  development  of  separate  data  base  documentation  which  has  different 
objectives  from  this  specification.  Each  file,  table,  or  dictionary  will  be 
described  in  detail  to  include  the  following  when  available: 


a.  Title  and  tag. 

b.  Description  of  content. 

c.  Parameters  -  start  of  file,  end  of  file. 

d.  Number  of  records  or  entries. 

e.  Record  parameters  -  start  of  record,  end  of  record. 

f.  Compool  status  of  each  record. 

g.  Storage  to  include  type  of  storage  and  address. 

h.  Normal  order  of  the  file  and  other  orders  required  for  special 
purposes. 

i.  File  classification. 


Storage  allocation  will  be  described  for  core  and  auxiliary  storage  as  follows: 

a.  Storage  media. 

b.  Available  storage  on  each  medium. 

c.  Addresses  of  available  storage. 

d.  Erasable  working  storage. 
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Data  retention  requirements  will  be  described  as  follows: 

Historic  retention  to  include  collection  of  data  to  be  retained, 

I 

format,  storage  medium,  and  time  parameters. 

Periodic  report  data;te.g. ,  time  retained  after  report  and  time 
retained  for  summary  reports. 

Summary  report  data  such  as  time  retained  after  summary 
report. 

Program  inter-relationship  with  data  base  will  be  described  to  show  files 
and  tables  used  in  each  program  function. 

•  *  !  • 

4.  5  Logical  Flow.  Paragraph  4.  5  shall  describe  the  logical  flow  of  the 
program.  Logical  flow  will  be  presented  primarily  in  the  form  of  charts 

i  '! 

prepared  in  accordance  with  Standard  50-15.)  A  narrative  presentation, 
when  appropriate,  will  be  used  to  supplement  the  flow  charts.  A  Program 
Specification  will  include  a  System  Logic  Chart  (that  portion  pertaining  |to 

I 

the  program).  Additional  charts  will  be  included,  such  as  Program  Logic 

•  i 

Chart  and  Ceding  Logic  Chart,  if  needed  to  support  the  use  to  be  made  of 

the  document.  All  program  charts  will  be  keyed  to  the  higher  order  charts 

! 

in  the  Subsystem  Specification  (if  applicable)  or  the  system  PFD.  The 
logical  flow  shall  provide  a  detailed  description  of  the  processing  performed 
by  the  program.  There  shall  be  included  for  each  program  function  noted 
in  paragraph  2.2  a  description  of  program  operation.  All  processes  will 
be  described  to  include  algorithmic  logic,  data  manipulations,  and  decision 
processes  involved.  Conditions  being  tested  for  purposes  of  branching 
will  be  explained  in  detail,  as  well  as  methods  for  identifying  error 


a. 

b. 

c. 
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conditions  and  resulting  actions  by  the  program.  The  charts  and  narrative 
will  be  related  to  the  information  in  paragraph  4.2  of  the  Subsystem  Speci¬ 
fication  (if  applicable).  Although  the  data  will  be  more  detailed,  it  must 
be  relatable  to  the  higher  order  documentation.  Changes  in  logical  flow 
which  have  occurred  will  be  explicitly  identified  and  reasons  for  the 
changes  stated. 
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APPENDIX  A 

SYSTEM  ABBREVIATIONS,  MNEMONICS,  AND  TERMS 

The  Appendix  will  provide  the  definitions  of  terms  or  phrase  definitions 
which  carry  connotations  unique  to  this  particular  system  or  which  are 
not  sufficiently  standard  as  to  be  adequately  defined  in  standard  diction¬ 
aries.  Item  names  and  location  tags  utilized  by  the  various  programs  of 
the  system  will  specifically  not  be  included  in  the  Appendix;  these  are  to 
be  completely  defined  in  the  body  of  the  specification.  The  Appendix  is 
intended  primarily  to  provide  definitions  of  terms  to  be  found  in  the  docu¬ 
mentation  writing  and  not  of  terms  unique  to  specific  programs.  The 
individual  terms  will  be  in  consonance  with  the  usage  in  the  other  docu¬ 
mentation  of  the  system. 
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1.  GENERAL  SPECIFICATION 

1.1  Purpose  of  Specification, 
guidance  for  the  preparation  of 

system  developer  when  required  as  a  part  of  a  NAVCOSSACT  project.  It 
is  apdjljjcable  to  all  projects. 

1.2  Scope  of  Specification 

1.2. 1  General.  Each  Data  Base  Specification  shall  include  information 
starting  with  Section  1  GENERAL  below  in  the  order  presented  and  under 
the  paragraph  titles  specified.  All  paragraphs  are  not  applicable  to  every 

i  . 

system  for  which  a  Data  Base  Specification  is  written  and  portions  not 
pertinent  to  a  particular  system  may  be  designated  not  applicable  by  the 

Project  Leader. 

i| 

V  !  . 

1.  2.  2  Reader  Orientation.  The  Data  Base  Specification  is  a  technical 
ADP  document  prepared  for  programmers.  It  is  to  be  sufficiently  detailed 
to  permit  program  coding  and  data  base  generation  by  the  developer. 

1.2.3  Formats.  Since  the  information  contained  herein  is  intended  to 
cover  all  types  of  program  systejms,  this  document  does  not  make  specific 
formats  mandatory.  It  is  presumed  that  the  system  developers  on  any 
given  system  are  best  qualified  to  devise  the  physical  formats  most  useful 
and  most  easily  comprehensible  to  the  project  personnel.  However,  to 
achieve  a  consistency  of  documentation  most  beneficial  to  all  personnel, 
the  following  rules  are  presented: 


INFORMATION 

This  documentation  specification  provides 
Data  Base  Specifications  by  a  computer 
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a.  In  all  DataBase  Specifications,  the  order  of  information  g. 
in  this  document  shall  be  followed. 

b.  In  all  Data  Base  Specifications,  each  formatted  presentati*  <i 
information  shall  be  followed  by  an  explanation  of  the  form  ted 
arrangement. 

c.  In  all  Data  Base  Specifications,  each  item  of  information  s  own 
in  a  formatted  presentation  shall  be  clearly  labelled. 

1.2.4  Criteria  for  Listings.  In  general,  all  listings  should  be  alph  : - 
beticaily  arranged  because  of  the  universal  acceptance  of  this  logics 
arrangement  of  information.  Other  logical  arrangements  are  accep  ible 
only  when  their  advantages  over  the  alphabetical  arrangements  are 
evident  and  the  logical  criteria  are  obvious.  For  instance,  in  this  d  f  u- 
ment,  program  entities  are  categorized  from  largest  to  smallest;  sto  age 
listings  are  arranged  by  storage  media. 


2.  CONTENT  OF  DATA  BASE  SPECIFICATION 

The  content  of  the  Data  Base  Specification  shall  be  in  accordance  wit  the 
format  on  the  following  pages. 
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1.  GENERAL 

1.1  Purpose  of  the  Data  Base  Specification.  Paragraph  1. 1  shall  describe 
the  purpose  of  the  Data  Base  Specification.  The  description  will  be  in 
accordance  with  the  following  NAVCOSSACT  objectives  for  the  preparation 
of  a  Data  Base  Specification: 

a.  Describe  storage  allocation  and  data  base  organteatioif. 

b.  Provide  the  basic  design  data  necessary  for  the  construction 

of  the  system  files,  tables,  and  dictionaries. 

/ 

1.2  Project  Reference.  Paragraph  1.2  shall  reference  the  project  title 
and  number  and  provide  a  brief  summary  of  the  project  objectives.  This 
paragraph  will  also  identify  the  project  sponsor  and  user(s). 

I  |. 

1.3  Applicable  Documents.  Paragraph  1.3  shall  provide  a  list  of  appli¬ 
cable  documents  by  number  and  title.  This  paragraph  will  include  at  least 
the  following  when  applicable: 

Preliminary  Functional  Description 
Subsystem  Specifications 
Program  Specifications 
Data  Requirements  Document 
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2.  DATA  BASE  IDENTIFICATION  AND  DESCRIPTION 
This  section  shall  provide  all  of  the  information  necessary  to  identify  and 
describe  the  data  base  being  documented.  It  shall,  in  addition,  contain 
various  kinds  of  background  information  essential  for  the  proper  utilization 
of  the  data  base. 

2. 1  Data  Base  Identification.  This  paragraph  shall  give  the  code  name, 
tag,  or  label  by  which  each  data  base  may  be  uniquely  identified.  Additional 
textual  information  shall  also  be  given,  whether  or  not  it  is  implied  in  the 
identification  code. 

2  11  Unique  Identification.  The  data  base  code  or  label  shall  be  stated. 

2.1  2  System(s)  Using  the  Data  Base.  The  system  of  which  this  data  base 
is  a  part  shall  be  accurately  and  thoroughly  identified.  Included  shall  be 
the  full  system  name,  system  code  name,  tag,  or  label,  and  system  model, 
modification,  or  version  number.  If  more  than  one  system  uses  this  data 
base,  then  each  of  them  shall  be  identified  in  the  above  manner. 


2.1,3  Effective  Dates.  The  first  and  last  dates  of  the  period  during  which 
this  data  base  may  be  used  with  Jie  above  named  system  shall  be  given. 

The  basis  of  the  selection  of  the  dates  may  vary.  They  may  correspond  to 
document  publication  dates,  program  testing  periods,  turnover  periods, 
turnover  or  delivery  dates,  etc. ,  depending  upon  the  implementation  plan 
being  used  for  the  system.  This  paragraph  shall  also  indicate  whether 
the  da*a  base  is  complete  or  incomplete,  pre-  or  post-system  delivery  to 
the  customer,  experimental  or  permanent,  supersedes  or  will  be  super¬ 
seded  by  another  data  base. 
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2.1.4  Physical  Description  of  Data  Base  Files.  The  physical  character¬ 
istics  of  the  Master  Data  Base  File(s)  and  duplicate  working  copies  shall 
be  given.  This  paragraph  shall  include  the  file  media  (card  decks  and/or 
tapes),  form  of  the  file  (symbolic  and/or  binary,  and  the  respective  codes 
used). 

2.2  Tagging  Conventions.  This  paragraph  shall  discuss  the  system 
tagging  conventions  to  the  extent  necessary  for  the  programmer  to  use  the 
conventions  as  a  practical  working  tool. 

2.3  Organization  of  the  Data  Base.  Paragraph  2. 3  shall  provide  system 
implementers  with  a  single,  central  source  of  major  design  considerations 
for  the  handling  of  the  data  base.  The  purpose  of  this  paragraph  is  to 
promote  consistency  of  design  concerning  the  organization  and  manipula¬ 
tion  of  the  physical  data  base  files. 

The  following  information  shall  be  given  for  each  kind  of  storage  medium 
containing  the  data  base  files: 

a.  General  file  design  and  format. 

b.  Rationale  of  the  design. 

c.  Illustrative  specific  examples. 


An  extensive  example  of  the  kind  of  information  to  be  presented  in  this 
paragraph  is  shown  below.  A  comparable  decimal  breakdown  shall  be 
provided  for  each  storage  medium. 
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2.3.1  Tapes 

2.3. 1. 1  System  Master  Program  Tape  (PMASTR--) 

a.  File  Design  and  Format.  The  System  Master  Tape  contains 
three  tape  files  as  shown  below. 


File  #1 


File  #2 


File  #3 


Tape  ID  Label 
(PMASTR--) 

EOF 


Directory  of 
Programs  in  File  HQ 

EOF 


Program  File 
2  Records  per  Program 
as  follows: 

Program  "A"  control  data 
Program  "A" 
Program  "B"  control  data 
Program  "B" 


Etc. 
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b.  Design  Rationale.  All  system  tapes  will  contain  an  identification 
label  as  the  first  tape  file.  All  tape  loading  programs  will  check 
the  labels  against  tape  identification  parameters  input  when  the 
system  is  intiaiized. 

The  second  tape  file  contains  the  tags  of  all  programs  in  the 
third  file  in  their  sequential  order,  plus  a  core/per  spheral 
storage  indicator.  The  loader  program  uses  this  to  locate  pro¬ 
grams  on  the  tape  and  to  construct  a  program  storage  directory 
table  in  core. 

The  third  tape  file  contains  2  records  per  program.  The  first 
contains  detailed  storage  data  about  the  program;  the  second 
contains  the  binary  program  itself.  The  tape  loader  moves  the 
programs  to  their  assigned  peripheral  storage  areas,  and  places 
the  contents  of  the  storage  records  into  the  permanent  storage 
directory  maintained  in  core. 

c.  Examples..*  Not  applicable  for  this  tape  (in  this  example,  the 
organization  of  this  physical  tape  file  was  explained  sufficiently 
in  a.  and  b.  above). 


2.4  Special  Instructions.  This  paragraph  shall  contain  the  instructions 
to  be  followed  by  all  personnel  who  will  contribute  to  the  compilation  of  the 
data  base  and  who  will  use  it  for  both  testing  and  operational  purposes. 

It  will  contain  information  such  as: 
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a.  Criteria  for  making  data  a  part  of  the  data  base. 

/ 

b.  Rules  and  procedures  to  be  followed  when  submitting  data  for 
entry  into  the  data  base. 

c.  Identification  of  a  data  control  unit,  if  applicable. 

d.  Formats  for  data  description  sheets  and  cards. 

e.  Machine  run  instructions  for  compiling,  modifying,  updating,  or 
otherwise  using  the  data  base  files.  In  very  large  systems,  where 
the  details  of  such  instructions  are  extensive,  this  paragraph 
may  reference  sections  of  other  programming  documents  (manuals 

or  specifications)  where  this  specific  information  can  be  found. 

’ 

2.  5  Utility  Tools  Available  for  Handling  the  Data  Base.  In  this  paragraph, 

i 

all  of  the  utility  and  support  programs  directly  related  to  the  data  base 
shall  be  either  referenced  or,  if  required,  discussed  briefly.  Descriptions 
shall  indlude  program  name,  functions,  and  major  program  operating 
considerations,  such  as  operating  time,  hardware  setup  required,  etc. 

The  detailed  program  specification  shall  also  be  cited.  If  only  referenced, 

i 

then  program  name,  document  title,  document  number,  and  appropriate 
sections1  of  the  document  shall  be  provided.  Examples  of  such  programs 


J  Assemble  Compool  Program 
Data  Base  (or  Compool)  Analyzer  Programs 
Storage  Allocator  Program 
Set/Used  Data  Analyzer  Program 
Data  Base  Loader  Program 
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Also  to  be  included  will  be  EAM  procedures  created  specifically  to  handle 
the  data  base.  These  may  include  procedures  such  as  card  sorts,  card- 
to-tape  makeup,  and  tape-to-printer  listings. 

3.  DATA  DEFINITIONS 

This  section  shall  include  thorough,  detailed  definitions  and  descriptions  of 
all  of  the  forms  of  data  utilized  by  the  system.  The  specific  details  of 
information  required  for  each  form  of  data  may  vary  from  system  to 
system  and  will  depend  on  the  design  characteristics  of  the  operational 
and/or  machine  operating  systems.  The  information  specified  below  is 
intended  to  cover  all  kinds  of  systems,  it  is  not  intended  to  be  totally  app¬ 
licable  to  any  system.  However,  the  Data  Base  Specification  for  a  given 
system  shall  include  all  of  the  information  applicable  to  that  system  in  the 
order  discussed  below. 

3. 1  Program  Entities.  This  paragraph  shall  list  program  entities  de- 

i 

fined  for  the  system.  They  shall  proceed  from  the  largest  program  entity 
to  the  smallest,  as  shown  below  in  3. 1. 1  through  3. 1.  5. 


3. 1. 1  Program  Subsystems,  This  listing  shall  include  all  largest-order 
program  groupings,  such  as  operational,  simulator,  utility,  and  mach¬ 
ine  operating  subsystems.  Descriptive  details  shall  include: 

Subsystem  tag  or  identification  code. 

'  Name  (in  full). 

Function  (describe  briefly) . 
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Estimated  or  actual  total  size. 

Storage  media  required,  plus  amount  required  of  each  medium 
and,  when  applicable,  actual  areas  of  each  medium  that  will 
be  occupied  by  the  subsystem. 

If  the  subsystem  is  used  in  more  than  one  system,  a  list  of  all 
systems  using  it. 

Major  operating  characteristics;  e.g. ,  real  time  or  not,  self- 
operating  or  under  executive  control,  has  exclusive  use  of 
machine  or  time-shares  it,  required  and  optional  hardware, 
operating  limits  and  constraints. 

A  list  of  all  next  lower-order  program  components. 

« 

3.1.2  Program  Functional  Areas.  Large  systems  may  have  large  groups 
of  programs  that  are  related  to  broad  operational  or  machine  functions. 
The  system  design  may  provide  a  clear-cut  definition  of  a  program  entity 
to  correspond  to  each  broad  function.  Examples  of  such  logical  program 
groups  are  those  that  perform  message  iijiput,  message  output,  inventory, 
payroll,  equipment  simulation,  tracking  and  intercept,  data  preparation, 
file  update,  information  retrieval,  and  restart  and  recovery.  Information 
required  to  define  such  functional  areas  is  similar  to  that  required  for  a 
program  subsystem  and  shall  include: 

Area  tag  or  identification  code. 

Name  (in  full). 

Function  (describe  briefly). 

Size  and  storage  media  requirements. 

Subsystem(s)  the  area  serves. 

Major  conditions  or  parameters  for  area  operation. 

A  list  of  all  next  lower- order  program  components. 
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3. 1. 3  Programs  Plus  Environment  Groupings.  This  category  of  data 
may  be  included  in  the  design  of  systems  where  blocks  of  core  or  per¬ 
ipheral  storage  files  contain  a  mix  of  programs  and  tables  that  are  oper¬ 
ated  as  a  single  entity.  The  word  ’’task”  has  been  used  for  such  logical 
groupings  that  perform  specific  functions;  e.  g. ,  message  interpretation, 
display  generation,  program  sequence  control  (an  executive  function),  and 
program  compilation.  Descriptive  information  for  this  program  entity  shall 
include: 

Logical  group  tag  or  identification  code. 

Name  (in  full). 

Specific  function  (describe  briefly). 

Parent  subsystem. 

File(s)  in  which  it  is  located. 

Storage  media  requirements. 

Storage  location  cf  this  task’s  directory,  parameters,  or  control 
table  (s). 

Lengths  of  shortest  and  longest  programs. 

Lengths  cf  shortest  and  longest  tables. 

Tags  cf  programs  that  are  entry  points  for  the  task. 

Tag  of  last  program  to  operate. 

Coded  task  termination  conditions  with  the  tags  of  the  item(s) 
and  table (s)  where  found. 

List  cf  programs  included  in  the  task. 

'  List  of  tables  included  in  the  task  (each  program  and  table  listed 
should  also  carry  an  indication  as  to  whether  or  not  it  is  used 
exclusively  by  this  task). 

Major  conditions  for  task  operation. 
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3. 1.4  Programs.  Each  program  in  a  system  shall  be  described  by  the 
following: 


Program  tag  or  identification  code,  including  its  model  or  version 
number. 

Program  name  (in  full). 

Brief  statement  of  program's  purpose. 

Parent  subsystem  indicator,  followed  by  other  subsystems  it 
serves,  if  applicable. 

Parent  task,  other  tasks  using  the  program,  if  applicable. 

File  location(s)  for  master  symbolic  and/or  binary  card  decks 
and  tapes. 

Estimated  or  actual  program  size. 

Peripheral  and  core  storage  area*  and  indication  of  permanent 
or  temporary  occupancy  of  core. 

Operating  mode  of  system  when  this  program  is  operated;  e.g. 
normal,  emergency,  initialization,  etc. 

Frequency  of  operation  (depending  upon  the  purpose  and  design  of 
the  particular  system,  this  item  may  contain  "once, "  "as 
required, "  "every  cycle,  "  "following  Program  XXX,  ”  or 
similarly  descriptive  terms). 

Program  entry  and  exit  points  (internal  tags,  relative  or  absolute 
addresses). 

Coded  entrance  and  exit  conditions. 

Location  or  items  containing  entrance  and  exit  conditions. 

Tables  used  by  this  program,  with  indication  as  to  whether  or  not 
the  table  is  for  exclusive  use  of  this  program. 
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3.1.5  Subroutines. 

This  paragraph  shall  list  all  subroutines  available  for 

use  by  the  system’s  programs.  Information  shall  include: 


Subroutine  tag  or  identification  code. 

Name  (in  full). 

Function  (describe  briefly). 

Size. 

Open  or  closed  subroutine  indicator. 

Subroutine  library  file  :  ame  and  location,  if  applicable. 


3.2  Data  Files.  A  datafile  is  a  logical  arrangement  of  information. 
However,  even  within  a  given  system,  the  diverse  data  files  usually  vary 
so  widely  in  their  logical  arrangements,  forms,  formats,  and  physical 
media  that  no  over-all  ruies  of  composition  or  conventions  apply  to  their 
construction.  There  is  only  one  rule  that  need  apply  to  all  data  files:  they 
must  all  bear  the  same  kind  of  tag  or  label  that  identifies  them  as  files  and 
not  some  other  kind  of  logical  arrangement  of  data.  Because  of  the  flex¬ 
ibility  in  data  file  construction  and  utilization,  each  one  should  be  defined 
as  explicitly  as  possible.  Information  shall  include: 


File  tag  or  label. 

Name  (in  full). 

A  brief  statement  of  the  file’s  purpose,  utilization,  and  logical 
criteria  used  for  the  file’s  compilation. 

The  largest  program  entity  using  the  file. 

Primary  and  secondary  storage  media. 
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File  contents  (depending  upon  the  complexity  and  size  of  the  fil»  , 
this  may  vary  from  a  listing  of  each  record  of  the  file  to  the 
broad  or  generic  categories  of  information  contained  therein). 
The  form  of  the  contents  (symbolic,  binary,  mixed). 

Conditions  for  modifying  or  updating  the  file. 

Method  of  modifying  or  updating  the  file. 

Restrictions  and  limitations  on  usage. 

Explicit  file  format. 

File  control  information  used  by  programs,  such  as  storage 
control  records,  directories,  pointers,  and  continue,  skip, 
and  end-of-file  markers. 

Graphic  representation  of  file  structure. 

3.3  Tables.  An  adequate  table  definition  shall  contain  the  following 
information  as  applicable: 

Table  tag. 

Full  name  and/or  purpose  of  the  table. 

Data  file  containing  the  table. 

Super-table  or  data  block  containing  the  table. 

Subsystem  that  uses  this  table. 

Logical  divisions  within  table  (internal  table  blocks  or  parts  - 
not  entries). 

Basic  table  structure  (fixed  or  variable  length,  fixed  or  variable 
entry  structure). 


I 
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If  fixed  table: 

Number  of  words  per  entry. 

Number  of  entries  in  table.  1 

If  variable  table:  I 

Maximum  length  (number  of  words).  |  l 

Maximum  number  of  entries  (if  entry  structure  is  fixed). 
Number  of  kinds  of  entries. 

Key  and  control  items  of  each  kind  of  entry. 

Indication  of  presence  or  absence  of  table  control  words 
(table  heading). 

Peripheral  and  core  storage  addresses. 

■  * 

Other  directly  related  tables  plus  a  statement  of  the  relationship. 
Example:  Table  SRCHO,  item  LOOKUP  contains  the  entry 
type  code  for  the  first  entry  in  this  table,  i 
Details  of  the  structure  of  each  entry  type  to  include: 

Graphic  representation  of  each  entry  type. 

Tag  of  each  item  plus  its  entry  word  number  and  bit  positions. 
Unique  or  significant  characteristics  such  as: 

"To-be  loaded  into  hardware  protected  registers  only. " 
"Contents  adapted  to  each  installation  (for  a  multi-site 
system). " 

"Use  of  this  table  illegal  except  under  emergency  mode  of 
operation. " 


3.4  Items.  As  used  in  this  paragraph,  the  word  "item”  refers  to  a 
specific  category  of  detailed  information  that  has  a  defined  position  within 
a  table,  and  that  is  coded  for  direct  and  immediate  manipulation  by  a  pro¬ 
gram.  Used  in  this  sense,  an  item's  definition  is  machine  and  program 
oriented  rather  than  operationally  oriented.  Item  definitions  shall  include: 

Item  tag, 

Purpose  of  the  item  (a  brief  statement). 

Table  in  which  it  is  found. 

Table  entry  type  in  which  it  is  found. 

Position  in  entry  (word  number  and  bit  positions). 

Item  use;  e.g. ,  table  control  item,  entry  structure  key  item, 

» 

string  control  item,  data  item. 

Item  type;  e.g.,  symbolic  character,  integer,  fraction,  mixed 
number  (fixed  or  floating  point)  string,  bead,  status. 

Item  coding,  depending  upon  the  item  type,  for  example: 

Symbolic  -  character  code  used. 

Integer  -  binary  or  binary  coded  decimal. 

Fraction  -  scaling  factor. 

Mixed  number,  fixed  point  -  point  position. 

Status  -  the  maximum  number  of  conditions,  form  of  status 
values  (symbolic  or  numeric  binary),  a  list  of  all 
acceptable  status  values  or  con^itiQQS^ 

Accessibility  factor  -  coded  to  indicate  machine  instruction  modi¬ 
fiers  that  can  expedite  fetching  and  storing  of  the  item;  e.g. , 
FW  (full  word),  LHW  or  RHW  (left-  or  right-hand  word), 

B  (byte  size),  M  (mask  necessary),  etc. 
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3.  5  Arrays.  Arrays  are  useful  for  expressing  groups  or  ranges  of  vari¬ 
ables,  each  of  which  is  related  to  two  or  more  distinct  elements,  aich  as  a 
temperature-humidity  matrix.  The  definition  of  an  array  shall  include. 


The  array  tag  or  identification  code. 

A  brief  statement  of  its  purpose  or  function. 

The  number  of  elements  (or  "dimensions”  of  the  array). 

The  name  and  meaning  of  each  dimension. 

The  number  of  cells  in  each  dimension. 

A  definition  of  each  item  in  the  array  (see  item  definition, 
paragraph  3.4). 

3.6  Records  and  Entries.  In  some  business  systems  the  basic  unit  of 
the  data  file  is  a  record  or  an  entry.  These  data  units  shall  be  as  thoroughly 
defined  as  tables  (see  Paragraphs  3. 3  and  3. 4).  In  addition  to  the  file 
structure  presented  in  the  language  of  the  compiler  being  used,  the  following 
information  shall  be  given:  _ ■_ _ _ _ ; _ _ _ _ _ _ 


Full  name  and  purpose  of  the  record  or  entry. 

An  explanation  of  each  item  in  the  data  unit. 

Maximum  size  of  data  unit. 

Graphic  representation  of  the  unit  as  it  is  contained  in  the  file, 
and  examples  of  the  output  obtained  from  the  file  with  signifi¬ 
cant  output  editing  features,  if  applicable. 
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This  section  shall  contain  all  of  the  internal  and  peripheral  storage  assign¬ 
ments  for  all  of  the  programs  and  data  of  a  system.  In  addition,  it  will 
contain  information  relevant  to  certain  constraints  and  conditions  under 
which  the  programs  must  operate.  Such  constraints,  based  upon  a  design 
for  the  most  efficient  utilization  of  the  system’s  storage  media,  can  apply 
to  both  autonomously  operated  systems  and  systems  that  function  within  the 
environment  of  larger,  machine  operating  systems. 


4. 1  Core  Map  for  the  System.  This  paragraph  shall  include  both  listings 
and  graphic  representations  showing  the  utilization  of  internal  storage. 

It  shall  include,  as  applicable,  the  following  information. 

Hardware  protected  program  areas. 

Hardware  protected  data  areas. 

Areas  set  aside  for  the  residence  of  permanent  programs  and  data 
(program  ’’overlay"  areas  and  data  "scratch"  or  working 
areas). 

This  paragraph  shall  also  contain  a  brief  statement  of  the  system  design 
considerations  that  resulted  in  the  system’s  core  utilization  scheme. 

4.2  Program  Storage  -  Core.  This  paragraph  shall  list  the  assigned  core 
storage  addresses  for  all  system  programs. 

t  \ 

4.2.1  Permanent  Core  Assignments.  This  paragraph  shall  include  all 
programs  permanently  assigned  to  core  storage. 
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4.2.2  Temporary  Core  Assignments.  This  paragraph  shall  include  all 
programs  with  temporary  core  assignements,  along  with  significant  condi¬ 
tions  or  criteria  pertinent  to  the  program’s  utilization  of  an  overlay  area 
(for  example,  timing  conditions  or  item  settings  used  by  an  Executive  to 
operate  this  program). 

4.3  Data  Storage  -  Core.  This  paragraph  lists  the  assigned  core  storage 
areas  for  all  of  the  system's  data  units  used  by  the  programs  (tables  or 
records,  I/O  buffer  areas,  etc.).  It  shall  list,  separately,  all  data  per¬ 
manently  assigned  to  core,  and  all  data  occupying  core  on  a  temporary  basis. 
In  addition,  there  shall  be  a  key  or  indicator  with  each  data  unit  linking  it 

to  its  peripheral  storage  location. 

4.4  Peripheral  Storage.  This  paragraph  shall  list,  by  device  and  sequen¬ 
tial  storage  area,  all  peripheral  storage  assignments  for  both  programs 
and  data.  The  storage  listing  for  each  device  shall  explicitly  state  all 
addresses,  areas,  blocks,  etc.  covering  the  following: 


Permanent  program  and  data  storage  assignments. 

Temporary  program  and  data  storage  assignments. 

Areas  reserved  for  special  purposes  such  as  testing,  experimental, 
or  emergency  use. 

Scratch  or  working  areas. 

Unused  areas. 

Logical  "slot1'  or  "cell"  arrangements. 
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5.  DATA/PROGRAM  RELATIONSHIPS 

/ 

Since  most  program  systems  contain  large  amounts  of  data  that  are  used 
by  more  than  one  program,  this  section  of  the  Dat?  Base  Specification  shall 
be  arranged  by  data  tag,  and  every  program  using  that  data  shal  be  indicated. 
The  particular  use  that  the  program  makes  of  that  data  (corresponding  to 

a. ,  b. ,  and  c.  below)  shall  also  be  indicated. 

A  program  '’uses”  data  when  it: 

a.  Stores  or  deposits  information  into  an  item. 

b.  Reads,  fetches,  or  examines  the  contents  of  an  item. 

c.  Both  stores  and  reads  the  contents  of  an  item. 

! 

'  '  ; 

*  .  : 

For  systems  in  which  data  is  not  formally  structured  into  tables,  this 
section  shall  list  all  item-level  tags  and  the  programs  using  the  item.  Where 
tables  are  used  as  data  units,  the  listing  shall  be  by  table  tag.  The  inclu¬ 
sion  of  larger  data  and  program  entities  in  this  section  (e.g. ,  data  files 
and  program  tasks)  shall  be  optional. 

6.  RELATIONSHIP  OF  OPERATIONAL  SYSTEM  DATA  TO  THE  INTERNAL 
DATA  BASE 

This  section  shall  cross-reference  the  nomenclature  of  system  data  used 
for  operational  purposes  with  the  data  nomenclature  used  for  programming 
purposes..  When  feasible,  the  cross-reference  shall  be  in  the  form  of  a 
thesaurus  containing: 
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Part  1.  Inputs 

The  following  shall  be  provided  for  each  piece  of  input  infor¬ 
mation: 

Name. 

Operational  significance  (stated  briefly) 

Primary  origin  (optional- 

Input  vehicle  (e.g. ,  message  label,  control  card  name, 
switch  setting,  etc. ) 

A  list  of  all  data  base  items  dependent  upon  that  input 
information  for  their  contents. 

* 

Part  2.  Outputs 

The  following  shall  be  provided  for  each  piece  of  output 
information: 

Name. 

Operational  significance. 

Ultimate  destination  (optional). 

Output  vehicle. 

A  list  of  all  data  base  items  from  which  the  information 
is  derived. 

Part  3.  System  Constants 

The  following  shall  be  provided  for  each  constant: 

Name. 

Operational  significance. 

Corresponding  data  base  item. 
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Part  4.  Control  Parameters 

The  following  shall  be  provided  for  each  parametrijc  item: 

Operational  name. 

Reason  for  its  use  as  a  parameter. 

(e.g. ,  ’’Defines  local  topography  at  each  ikdar  site”) 

*  J.  |< 

A  list  of  data  base  items  dependent  upon  this  parametric 
information. 

Note:  The  control  parameters  included  here  are  influential 
in  controlling  the  total  system  operation.  They  are  not 

normally  input  during  the  system’s  operations.  Examples  are: 

i 

1  '  i  ' 

Equipment  configuration  descriptors,  especially  in  a 
multi-site  system. 

Mode  of  operation  directives. 

Time  synchronization  items. 


It  is  recognized  that  many  normal  system  input  itgms  are  also 

parameters,  but  they  will  be  included  in  Part  1  above. ■**’’** ' 

\  4  ' 

If  the  volume  of  data  in  a  given  system  is  so  great  that  a  complete  thesaurus 
is  not  feasible  as  part  of  the  data  base  specification,  then  a  substitute  data 
cross-reference  plan  must  be  specified.  Some  possible  alternatives  are 
given  below: 
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Publication  of  a  separate  data  thesaurus  which  will  be  referenced 
in  this  section  of  the  Data  Base  Specification. 

A  cross  index  of  message/display  labels  or  titles  and  table  tags, 
with  detailed  references  to  the  documents  describing  the 
messages/displays  in  detail. 

Categorization  of  specific  operational  functions,  listing  under  each 
function:  inputs,  outputs,  and  tables  used,  with  references  to 
appropriate  separate  documents. 

None  of  the  above  alternatives  are  as  thorough  as  a  thesaurus,  but  for  very 
large  systems  they  may  be  adequate  and  in  terms  of  time,  effort,  and  cost, 
they  may  outweigh  the  advantages  of  a  thesaurus. 
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APPENDIX 

SYSTEM  ABBREVIATIONS,  MNEMONICS,  AND  TERMS 


The  Appendix  will  provide  the  definitions  of  terms  or  phrase  definitions 
which  carry  connotations  unique  to  this  particular  system  or  which  are  not 
sufficiently  standard  as  to  be  adequately  defined  in  standard  dictionaries. 
Item  names  and  location  tags  utilized  by  the  various  programs  of  the  system 
will  specifically  not  be  included  in  the  Appendix,  these  are  to  be  completely 
defined  in  the  body  of  the  specification.  The  Appendix  is  intended  primarily 
to  provide  definitions  of  terms  to  be  found  in  the  documentation  writing  and 
not  of  terms  unique  to  specific  programs.  The  individual  items  will  be  in 
accordance  with  the  usage  in  the  higher  order  documentation. 
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1.  GENERAL  SPECIFICATION  INFORMATION 


1.1  Purpose  of  Specification.  This  documentation  specification  provides 
guidance  for  the  preparation  of  Staff  Manuals  by  a  computer  system 
developer  when  required  as  a  part  of  a  NAVCOSSACT  project. 


1.2  Scope  of  Specification 


1. 2. 1  General.  Each  Staff  Manual  shall  include  the  information  starting 
with  Section  1  GENERAL  DESCRIPTION  below  in  the  order  presented 
in  this  specification  and  under  the  paragraph  titles  specified.  All  para- 

I 

graphs  are  not  applicable  to  every  system  for  which  a  Staff  Manual  is 
written  and  portions  not  pertinent  to  a  particular  system  may  be  designated 
not  applicable  by  the  Project  Leader.  At  the  discretion  of  the  Project 
Leader,  this  document  may  be  combined  with  the  Operations  Manual  and 
the  Program  Maintenance  Manual  into  a  single  volume,  three  part  docu¬ 
ment  retaining  the  same  numbering  system  and  presenting  the  same 
information  as  stated  for  each  individual  document.  Part  1  will  be  the 
Staff  Manual,  Part  2  will  be  the  Operations  Manual  and  Part  3  will  be  the 

Program  Maintenance  Manual.  This  single  volume  will  be  called  the 

j 

Project  Manual.  | 

1.  2. 2  Reader  Orientation.  The  Staff  Manual  presents  general  and  applied 
information  on  a  specific  computer  system.  It  is  directed  toward  an 
organization's  general  management  and  staff  personnel  and  the  management 
and  staff  of  the  affected  operating  divisions  and  functional  areas.  The 
Staff  Manual  meets  the  requirement  of  those  who  need  or  desire  an  overall 


NAVCOSSACT 

SUBJECT 

NUMBER 

40-35 

STANDARDS 

STAFF  MANUAL 

PAGE 

4 

OF 

19 

appreciation  of  the  system  but  have  no  need  for  detailed  technical  informa¬ 
tion  concerning  system  implementation  or  operation.  The  descriptive 
material  shall  serve  to  orient  the  reader  and  inform  him  of  the  system 
functions  and  capabilities  with  respect  to  the  ADP  facility  and  the  affected 
general  operational  organizations  or  command.  This  information  shall 
also  tell  the  reader  how  to  use  the  system  when  required. 

2.  CONTENT  OF  THE  STAFF  MANUAL 

The  content  of  the  Staff  Manual  shall  be  in  accordance  with  the  format  on 
the  following  pages  through  Appendix  B. 
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1.  GENERAL  DESCRIPTION 

1. 1  Purpose  of  the  Staff  Manual.  Paragraph  1. 1  shall  describe  the 
purpose  of  the  Staff  Manual  The  description  will  be  in  accordance  with 
the  following  NAVCOSSACT  objective  for  preparation  of  a  Staff  Manual: 

Provide  the  Staff  (ncn-ADP)  personnel  of  the  user  with  the 
information  necessary  tc  effectively  use  the  system. 

1.  2  System  Application.  The  application  cf  the  system  and  its  uses 
supporting  functional  activities  of  the  command  organization  and/or  in 
supporting  program  operations  in  the  ADP  facility  shall  be  generally 
stated  and  explained.  The  description  shall  include: 

a.  Application  purpose,  reason  or  rationale.! 

,  ( 

b  Capabilities  and  operating  imprcveihents  provided  by  the  system. 

— c.  . .Additional  features,  characteristics,  ana  advantages  considered 

appropriate  in  furnishing  a  clear  and  complete  description  of  the 
system  application  and  the  benefits  derived  from  it. 
d.  Functions  performed  by  the  system  under  the  application  such 
as  pre-processing  or  pcst-processing  data  input  to  or  output  from 
a  primary  processor;  maintenance  cf  data  files;  translation  of 
source  language  programs;  control  sequencing  of  operating 
program  runs. 
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1.3  System  Operation.  This  paragraph  will  show  the  relationships  between 
the  ADP  functions  for  either  functional  or  support  type  systems  and  the 
several  functional  areas  or  activities  of  the  organization  that  are  sources 
of  input  to  the  system  and/or  are  recipients  of  output  from  it.  An  infor¬ 
mation  flow  diagram  of  the  type  illustrated  in  NAVCOSSACT  STD  50-15 
Program  System  Chart  Types  shall  be  used.  A  brief  narrative  description 
accompanying  the  information  flow  diagram  should  tell  the  reader  only 
the  who,  what,  where  and  why  concerning  inputs  and  outputs  associated 
with  the  system  information  flow  chart. 


1.4  System  Configuration.  A  brief  narrative  description  of  the  system’s 
equipment  shall  be  given  for  the  clarification  of  the  reader.  This  may 
include  the  type  of  computer  and  the  array  of  peripheral  equipment. 

1.  5  Performance.  This  paragraph  shall  inform  the  reader  of  the  overall 
performance  of  the  system  or  how  well  it  meets  the  organization’s 
information  requirements  or  supports  associated  activities.  Performance 
measures  and  data  of  interest  would  be  represented  by  the  following 
examples : 

a.  Error  Rate  -  also  describe  program  system  capabilities  in 
detecting  various  legal  and  logical  errors  and  the  means 
provided  for  error  correction. 

b.  Response  Time  -  also  include  qualifications  where  necessary 
that  affect  response  time  in  processing  operational  reports, 
listing  a  tape,  compiling  an  object  program,  etc.  Factors  such 
as  type  and  volume  of  input  and  equipment  configuration  are 
examples  of  items  that  may  influence  running  time. 
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c.  Accuracy  -  when  numerical  outputs  are  produced  state  accuracy 
in  terms  understood  by  reader,  e.g. ,  accuracy  to  3  decimal 
places  vs  accuracy  to  6  binary  bits. 

d.  Input  -  Types,  volumes,  rate  of  inputs  accepted  by  the  program 
system. 

e.  Output  -  Types,  volumes,  rate  of  output  that  the  system  can 
produce. 

f.  Limitations  -  For  example,  max.  size  per  unit  of  input;  format 
constraints;  restrictions  on  what  datafiles  may  be  queried  and 
by  what  location;  language  constraints  as  a  function  of  compiler 
design. 

g.  Flexibility  -  note  provisions  allowing  extension  of  the  application 
of  the  system. 

h.  Reliability  -  note  system  provisions  that  support  alternate 
processing  or  a  switch-over  capability,  as  examples. 

I 

1. 6  System  Organization.  The  objectives  here  shall  be  to  provide  the 
reader  with  a  general  understanding  of  the  system'*?  organization.  A 
hierarchical  or  ’’tree”  type  of  presentation  shall  be  given  that  shows  as 
appropriate  the  logical  parts  of  the  system  such  as  subsystems  and  pro¬ 
grams  with  a  brief  description  of  each  telling  the  reader  its  role  in  the 
operation  of  the  system. 

1.  7  Data  Base.  The  data  files  that  are  referenced  and/or  supported  or 
kept  current  by  the  system  shall  be  described.  These  files  shall  be 
identified  in  operational  or  functional  terms  rather  than  by  program 
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designations  for  the  benefit  of  the  general  reader.  The  brief  description 
should  include  the  type  of  data  in  the  file  and  the  usage  made  of  it. 

1.8  General  Description  of  Inputs,  Processing,  Outputs.  This  paragraph 
shall  present  a  general  narrative  description  of  the  inputs,  the 
flow  of  data  through  the  processing  cycle,  and  the  resultant  outputs. 
Representative  items  for  consideration  are  the  following: 


a.  Purpose  of  input  -  explain  why  the  input  is  made  to  the  program 
system  and  note  conditions  or  events  requiring  its  submission. 

b.  Content  of  input  -  describe  what  the  input  contains  in  the  way  of 
operational,  control,  or  reference  data  for  the  system. 

c.  Associated  Inputs  -  reference  inputs  required  by  the  system  with 
this  input. 

d.  Origin  of  inputs  -  identify  the  source  or  preparer  of  the  input. 

e.  Data  Files  -  identify  in  general  or  functional  terms  the  files 
associated  with  the  input. 

f.  Other  -  additional  remarks  supporting  a  complete  tabulation  of 
general  information  on  inputs  to  the  system. 

g.  Processing,- relate  input  to  output  with  a  general  description  of 
the  flow  of  data  through  the  processing  cycle. 

h.  Output  -  list  outputs  produced  by  the  system  as  a  consequence  of 
the  input . 

i.  Purpose  of  output  -  explain  the  reason  for  the  output  and  note 
conditions  or  events  that  require  its  generation  by  the  system. 

j.  Content  of  output  -  describe  in  general  terms  the  information 
provided  by  the  output. 
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k.  Associated  Outputs  -  reference  other  system  outputs  that 
complement  the  information  in  this  output. 

l.  Distribution  outputs  -  note  the  recipients  in  the  ADP  or  other 
functional  areas  of  the  organization  who  receive  this  output. 

m.  Other  -  additional  items  that  contribute  to  a  complete  tabulation 
of  general  information  on  the  system  outputs. 

2.  TECHNICAL  OPERATIONS 

Section  2  of  the  Staff  Manual  shall  provide  the  reader  with  all  the  details 
necessary  to  prepare  inputs  to  the  system.  The  scope,  quality,  and 
logical  arrangement  of  the  information  shall  enable  the  staff  and  opera¬ 
tional  personnel  to  prepare  inputs  required  by  their  operations  correctly 
and  expeditiously.  In  addition,  this  section  will  explain  in  detail  the 
characteristics  and  meaning  of  the  information  the  system  produces  as 
outputs. 

2. 1  Input  Requirements.  The  requirements  to  be  observed  in  preparing 
entries  to  the  system  shall  be  delineated  here  for  each  class  of  input. 
Typical  considerations  are  the  following: 

a.  Cause  of  input  -  what  operational  conditions  require  submission 
of  the  input  (e.  g. ,  catastrophe;  normal  status  report;  need  to 
translate  input  data  or  a  source  program;  desire  to  query  a  data 
file). 

b.  Time  of  input  -  when  must  the  input  be  received  by  program 
system  (e.g. ,  periodically;  randomly  as  a  function  of  an 
operational  situation). 
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c.  Origin  of  input  -  identify  activity  or  location  authorized  to 

/ 

generate  the  entry. 

d.  Forms  of  input  -  identify  format  or  layout  sheet  of  card  required 
to  compose  the  input.  Also,  note  the  need  of  a  job  submission 
or  request  for  ADP  services  form,  which  represents  a  formal 
interface  between  Staff  and  ADP  Control  personnel.  The 
provisions  in  the  form  for  entering  items  such  as  processing 
required,  disposition  and  retention  of  data  are  to  be  described. 

e.  Medium  of  input  -  note  the  medium  on  which  the  input  is  entered 
into  the  processor  (e.g. ,  punched  card;  mag  or  paper  tape; 

| 

keyboard). 

f.  Associated  Inputs  -  reference  related  inputs  (explained  also  in 
this  Section  2)  that  are  required  to  be  entered  at  time  of  this 

I 

input. 

g.  Other  -  note  applicable  information  such  as  non-machine 

.  recipients  of  the  entry;  priority  and’  security  handling;  variations 
|  on  the  basic  entry  format  using  code  or  key  indicators;  limitations 

on  what  files  may  be  interrogated  by  a  query  type  of  input. 

2. 2  Composition  Rules.  This  paragraph  shall  provide  a  description  of 
the  language  and  the  grammatical  rules  and  conventions  that  must  be 
observed  in  order  to  write  entries  that  can  be  "read"  by  the  program 
system.  The  rules  of  syntax,  usage  of  punctuation,  and  the  allowed 
vocabulary  will  be  explained.  Items  for  consideration  may  include  the 
following: 
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a.  Input  Length  -e.g. ,  100  characters  max. 

b.  Line  Length  -  e.g. ,  30  characters  max. 

c.  Format  -  e.g. ,  all  entry  items  left  -  justified. 

d.  Labeling  -  i.  e. ,  usage  of  tags  or  identifiers  to  denote  major 
data  sets  to  the  system. 

e.  Sequencing  -  i.  e. ,  the  order  and  placement  of  items  in  the 
input. 

f.  Punctuation  -  i.e. ,  spacing  and  use  of  symbols  (virgule;  asterisk; 
character  combinations;  etc.)  to  denote  start  and  end  of  input, 

of  lines,  of  data  groups,  etc. 

g.  Combination  -  i.  e. ,  rules  forbidding  the  use  of  particular 
character  or  parameter  sets  in  an  input  to  system. 

2.3  Vocabulary.  This  paragraph  shall  explain  the  appended  listing  of 
legal  character  combinations  or  codes  that  are  used  to  identify  or  compose 
input  items  such  as  mission  or  operation;  ddta  file  or  a  call-up  parameter; 
inventory  item;  statements  or  operations. 

2.4  Input  Formats.  The  layout  form(s)  used  in  the  initial  preparation  of 
system  inputs  shall  be  illustrated  and  the  information  which  may  be  entered 
on  the  various  sections  and  lines  explained.  The  explanation  of  each  entry 
provision  shall  be  keyed  to  the  sample  form  illustrated. 

2.5  Sample  Inputs.  Each  class  or  type  of  entry  acceptable  by  the  system 
shall  be  illustrated.  An  introduction  will  be  given  as  to  the  circumstances 
or  reasons  for  the  generation  of  the  input  or  in  other  words  what  the 
sample  represents.  Then,  a  complete  explanation  shall  follow  on  the 
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significance  of  the  entries  in  the  sample  input.  Typical  items  to  be 
explained  can  include: 

a.  Control  or  Header  -  containing  entries  that  denote  input  class 
or  type;  date/time;  origin;  instruction  code  to  system;  etc. 

b.  Text  -  containing  single  entries  and  group/sub-group  items 
representing  data  for  operational  files;  request  parameters 
for  an  information  retrieval  program;  etc. 

c.  Tail  or  Trailer  -  containing  end  of  input  and  additional  control 
data. 

d.  Omissions  -  indicate  those  items  or  groups  that  may  be 
omitted  at  the  option  of  the  composer  or  because  of  particular 
circumstances  concerning  the  input. 

e.  Repeats  -  indicate  those  items  or  groups  that  may  be  repeated 
up  to  a  specified  ; 
the  composer. 

2.6  Output  Requirements, 
output  shall  be  described.  Representative  items  that  may  be  included  are: 

a.  Purpose  -  concerning  the  reason(s)  why  the  output  is  generated 
such  as  a  consequence  of  an  input  or  the  existence  of  an 
’’exception”  situation. 

b.  Time  -  indicate  if  the  output  is  randomly  or  periodically 
produced. 

c.  Modes  -  concerning  modifications  or  variations  of  information 
provided  by  the  basic  output  type. 
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d.  Medium  -  concerning  physical  form  of  output  such  as  printout, 
tape,  screen,  cards,  cathode- ray  tube  (CRT). 

e.  Location  -  concerning  where  the  output  is  required  to  appear 
such  as  in  the  ADP  area  or  remotely  at  a  functional  area  (e.  g. , 
Materiel  Control). 

f.  Other  -  note  additional  requirements  for  this  output  such  as 
priority  and  security  handling;  associated  outputs  that  complement 
the  information  in  this  output. 

2.  7  Output  Formats.  The  layout(s)  in  which  the  system  output(s)  is 
presented  shall  be  explained  in  detail.  Explanations  shall  be  keyed  to 
particular  parts  of  the  f ormat(s)  illustrated.  Appropriate  items  in  an 
output  format  that  may  be  considered  include  the  following: 

a.  Header  -  title,  identification,  time,  number  of  output  parts  and 
similar  basic  control  datath.il  maybe  contained  in  an  output's 
header  or  control  segment 

b.  Body  -  note  the  information  that  may  appear  in  the  body  or  text 
of  the  output  format.  Describe  the  significance  of  fixed  data  in 
the  body  such  as  columnar  headings  in  tabular  display  types  of 
output.  Also  note  the  existence  of  sub-sets  or  sections  in  the 
output  format  (e.g. ,  PART  A,  PART  B).  In  Card/Tape  output 
describe  the  position  or  column  locations  allocated  to  specific 
output  information. 

c.  Tail  -  note  provisions  for  control  or  reference  information  that 
may  be  appended  to  the  body  of  information  presented. 
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Additional  characteristics  concerning  the  make-up  of  outputs  may  include 
items  such  as  suppression  of  leading  zeros  for  numerical  information  and 
a  maximum  number  of  characters  per  item,  thereby  requiring  the  use  of 
abbreviated  entries  in  the  output, 

2.  8  Sample  Outputs.  Illustrations  of  the  type  of  output  obtainable  from 
the  system  shall  be  given  for  each  different  class  of  output.  The  function 
or  purpose  of  the  sample  or  dummy  output  shall  be  explained.  A  detailed 
description  will  then  follow  for  the  items  shown  in  the  sample.  The 
following  points  will  be  included  in  the  description; 

a.  Definition  -  the  meaning  and  use  of  each  information  variable 
for  the  reader  or  user. 

b.  Source  -  item  extracted  from  a  specific  input;  from  a  data  base 
file;  calculated  by  system;  etc. 

c.  Characteristics  -  concerning  item’s  omissibility  under  certain 
conditions  of  the  output  generation;  range  of  values;  unit  of 
measure. 

2.  9  Utilization  of  Outputs.  Primarily  for  the  outputs  from  functional 
systems  an  explanation  shall  be  given  of  the  application  of  the  output  in 
the  operational  area  or  activity  which  receives  it.  A  summary  report  of 
POL  stocks,  for  example,  would  be  received  by  a  materiel  control 
activity.  Depending  on  the  information  in  the  report,  action  might  be 
required  to  initiate  the  purchase  or  transfer  of  materiel  to  a  particular 
location. 


SUBJECT 

STAFF  MANUAL 

BIBLIOGRAPHY 

The  bibliography  will  provide  a  list  of  direct  and  indirect  references 
which  are  worthy  of  note  by  the  readers.  Each  entry  will  contain  Title, 
Date,  Document  Number  and  Classification,  Author,  and  Publisher  if 
applicable.  The  title  of  books,  papers,  reports,  and  pamphlets,  will  be 
underscored;  the  titles  of  articles  within  a  publication  will  be  placed  in 
quotation  marks.  The  entries  will  be  arranged  alphabetically  by  author. 
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APPENDIX  A 

SYSTEM  ABBREVIATIONS,  MNEMONICS,  AND  TERMS 


The  Appendix  will  provide  the  definitions  of  terms  or  phrase  definitions 
which  carry  connotations  unique  to  this  particular  system  or  which  are 
not  sufficiently  standard  as  to  be  adequately  defined  in  standard  diction¬ 
aries.  Item  names  and  location  tags  utilized  by  the  various  programs 
of  the  system  will  specifically  not  be  included  in  this  Appendix;  these  are 
to  be  completely  defined  in  the  body  at  the  document  or  separate  appen¬ 
dices.  This  Appendix  is  intended  primarily  to  provide  definitions  of  terms 
to  be  found  in  the  documentation  writing  and  not  of  terms  unique  to 
specific  programs. 
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GLOSSARY  OF  ITEM  CODES 
This  appendix  will  provide  the  following  information: 

I, . .  . 

.  a.  An  alphabetical  listing  of  item  code^  that  can  be  entered  into  an 
input  to  the  system  or  that  can  appear  on  an  output  from  the 
system. 

b.  An  alphabetical  listing  of  functional  or  generic  categories,  e.  g. , 

materiel  control,  weather,  ship  type.  Each  of  these  basic  | 

| 

categories  will  contain  an  alphabetical  listing  of  associated  data 
items  and  their  code  representation. 
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3.  DOCUMENT  REVIEW 

3. 1  Preliminary  Review.  The  preliminary  draft  of  the  proposed  Staff 
Manual  shall  be  given  a  preliminary  review  to  determine  that  the  material 
contained  therein  is  sufficiently  complete  to  warrant  the  preparation  cf 
a  final  copy.  Acceptance  or  approval  of  a  preliminary  draft  in  the  course 
of  preparation  cf  the  proposed  Staff  Manual  shall  in  no  case  be  construed 
as  a  guarantee  of  acceptance  of  the  final  copy.  The  preliminary  review 
shall  include,  but  not  necessarily  be  limited  to,  a  review  of  the  following 
features: 


a.  Application  of  reference  documents 

b.  Format  and  arrangements 

c.  Style  and  phrasing 

d.  Suitability  of  headings 

e.  Length  of  paragraphs 

f .  Physical  lengths  of  the  document 

g.  Correctness  of  cross  references 

h.  Numbering 

i.  Use  of  abbreviations  and  symbols 

j.  Grammar 

k.  Punctuation 

l.  Technical  accuracy  and  clarity 

m.  Technical  completeness 

n.  Absence  of  contractual  information 
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3.  2  Final  Review.  The  final  copy  of  the  proposed  Staff  Manual  shall  be 
given  a  final  review  to  determine  that  the  requirements  of  this  specifica¬ 
tion  have  been  satisfied.  Final  review  will  include,  but  not  necessarily 
be  limited  to,  a  review  of  the  features  listed  under  preliminary  review 
and  the  following: 

a.  Quality  of  duplimat 

b.  Quality  of  typing 

c.  Reproducibility 

4.  PROCUREMENT  DATA 

•  / 

4.1  Ordering  Instructions.  Procurement  documents  concerning  Staff 
Manuals  should  specify  the  following: 

a.  Title,  number,  and  date  of  the  Staff  Manual 

b.  Applicable  requirements  for  packing,  packaging  and  shipment 
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1.  GENERAL  SPECIFICATION  INFORMATION 

/  '  .  . ‘  '  ■ 

1. 1  Purpose  of  Specification.  This  specification  provides  guidance  for 
the  preparation  of  an  Operations  Manual  by  a  computer  system  developer 
when  required  as  part  of  a  NAVCOSSACT  project. 

1.2  Scope  of  Specification. 

1.2. 1  General.  Each  Operations  Manual  shall  include  the  information 
starting  with  Section  1.  GENERAL  DESCRIPTION  below  in  the  order 
presented  in  this  specification  and  under  the  paragraph  titles  specified 
All  paragraphs  are  not  applicable  to  every  sjatem  for  which  an  Operations 
Manual  is  written,  portions  not  pertinent  to  a  particular  system  may  be 
designated  as  not  applicable  by  the  Project  Leader.  At  the  discretion  of 
the  Project  Leader,  this  document  may  be  combined  with  the  Staff  Manual 
and  the  Program  Maintenance  Manual  into  a  single  volume,  three  part 
document  retaining  the  same  numbering  system  and  presenting  the  same 
information  as  stated  for  each  individual  document.  Part  1  will  be  the 
Staff  Manual,  Part  2  will  be  the  Operations  Manual  and  Part  3  will  be  the 
Program  Maintenance  Manual.  This  single  volume  will  be  called  the 
Project  Manual. 

1.2.2  Reader  Orientation.  The  Operafions  Manual  prepared  in  accordance 
with  the  requirements  of  this  specification  m h a  1 1  contain  precise  and  de¬ 
tailed  information  on  the  control  requirements  and  operating  procedures 
necessary  to  successfully  initiate,  run.  and  terminate  the  operations  of 
the  subject  system.  It  is  directed  toward  Management,  Supervisory,  and 
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Operator  personnel  who  are  responsible  for  the  efficient  performance  of 
their  organization’s  ADP  facility.  These  readers  are  primarily  interested 
in  detailed  information  on  the  system's  external  characteristics  and 
operating  procedures.  In  general  the  manual  shall  be  written  in  a  step- 
by-step  fashion  as  opposed  to  an  expository  style  in  order  to  clarify  and 
emphasize  the  procedures  associated  with  the  system.  The  Operations 
Manual  shall  be  completely  self-contained.  Supporting  illustrations  shall 
be  concerned  with  the  flow  of  input  data  and  output  information  but  shall 
not  present  breakdowns  or  delineations  of  the  system's  internal  logic  and 
flows  such  as  are  depicted  in  program  flow  charts. 


2.  CONTENT  OF  OPERATIONS  MANUAL 

The  content  of  the  Operations  Manual  shall  be  accordance  with  the  format 
on  the  following  pages  through  the  Appendix. 
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1.  GENERAL  DESCRIPTION 


1. 1  Purpose  of  Operations  Manual,  Paragraph  1. 1  shall  describe  the 
purpose  cf  the  Operations  Manual,  The  description  will  be  in  accordance 
with  the  following  NAVCOSSACT  objective  for  preparation  of  an  Operations 
Manaul: 


Provide  control  and  operator  personnel  with  a  general  description 
of  the  system  and  its  associated  environment  with  \thich  they  will 
be  concerned  during  the  performance  of  their  duties. 


1, 2  System  Application,  A  brief  description  of  the  system  shall  be  given 

which  tells  the  reader  the  title,  project  number  and  use(s)  of  the  system. 

0 

i 

1.  3  System  Operation.  This  paragraph  shall  describe  the  operation  of 
the  system  by  use  cf  an  Integrated  ADP  Flow  Chart  (NAVCOSSACT  STD 
50-15  Figure  5)  which  will  shbw  hew  the  several  runs,  tasks,  and  jobs 
are  interrelated  in  regard  to  input  data  and  output  information.  If  sets 

of  runs  are  grouped  bv  periods  of  time  cycles  then  each  set  of  integrated 

i 

operations  required  on  a  daily .  weekly,  etc,  basis  will  be  presented. 

The  inter-  relationships  among  the  system  tasks  in  respect  to  timing  and 
input/ e utput  data  are  cf  primary  importance  to  control  personnel.  The 
diagram  blocks  shall  be  labeled  to  indicate  appropriate  Jiame  or  number 
and  purpose.  The  input  and  output  symbols  denoting  cards,  tapes,  etc, , 
that  are  shewn  associated  with  their  particular  run  or  operation  and  are 
;»sm  cia'ed  with  other  runs  or  ( perations  as  inputs  or  outputs  shall  also 

i  i 

be  identified  as  u  name  and  type  of  their  data  content. 


i 
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1.4  Program  Inventory.  This  paragraph  shall  provide  an  inventory  in 
tabular  form  of  the  programs,  tasks,  and  runs  in  the  system.  Each 
component  of  the  system  shall  be  identified  by  title,  number,  and  mnemonic 
reference  as  applicable.  The  use(s)  of  each  component  and  the  approximate 
timing  requirements  of  each  component  will  also  be  given, 

2.  SYSTEM  CONTROL 

Section  2  of  the  Operations  Manual  shall  present  information  oh  how  the 
operations  and  environment  associated  with  the  system  are  controlled  so 
that  scheduling  of  operations,  assignment  of  equip ir>~"ts,  and  the  manage¬ 
ment  of  input  data  and  output  information  proceed  in  an  orderly  and  produc¬ 
tive  manner.  This  type  of  Information  is  of  practical  use  to  ADP  manage- 

t 

ment  and  control  personnel,  since  it  is  reflected  in  their  standard  practices 
and  regulations  governing  the  operation  of  their  ADP  facility.  In  on-line 
systems,  some  of  the  description  on  system  operational  control  will  be  re¬ 
lated  to  the  capability  of  the  supervisory  type  of  program  which  functions  as 
a  real-time  controller  of  the  operations  and  environment  of  a  system. 

2. 1  Control  Requirements.  This  paragraph  shall  present  clear  and  concise 
instructions  for  control  personnel,  who  are  responsible  for  administration 
and  control  of  a  computer  application  from  receipt  of  input  to  delivery  of 
output.  Items  to  be  represented  should  include  processing  cycles  (daily, 
weekly,  etc. ),  coordination  and  control  of  input,  library  and  output  material, 
and  the  composition  of  instruction  forms.  The  following  items  are  repre¬ 
sentative  of  control  considerations  which  may  be  applicable: 
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a.  Receipt  and  identity  of  input  data. 

b.  Data  preparation  instructions. 

c.  Control  card  preparation. 

d.  Preliminary  EAM  processing  instructions  (major  EAM  operations 
are  to  be  presented  in  detail  in  Section  3). 

e.  Sequence  of  input. 

f.  Quality  control  technique. 

g.  Disposition  cf  output. 

h.  Disposition  of  source  media  (cards,  transcripts,  etc. ) 

i.  Control  forms  (see  paragraph  2.  2). 

j.  Deck  Sequence  (see  paragraph  2.  4). 

k.  Phasing  (  see  paragraph  2.  3). 

l.  Graphic  Processing  Chart  (see  paragraph  2.  5). 

m.  Tape  Retention  Schedules  (see  paragraph  2.  6). 

n.  Queries  (see  paragraph  2.  7). 

2.  2  Control  Forms.  This  paragraph  shall  present  illustrations  of  the 
applicable  forms  that  support  the  various  system  control  requirements. 
Each  form  shall  be  identified  by  name/title,  form  number,  and  functional 
use  in  the  scheme  of  control.  The  significance  of  each  entry  provision 
in  the  fc  rm  shall  be  explained  for  the  reader.  The  following  are  the  min¬ 
imum  control  forn.s  needed: 

a.  User  Request  -  This  form  should  be  designed  to  facilitate  rapid 
recognition  of  users’  requirements  and  designed  to  interface  with 
centre!  instructions.  Contingent  upon  the  project  design,  the  form 
should  include  the  following  information: 
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Date. 

Originator. 

Processing  cycle/or  option  required. 

Date  required. 

File  Mas  of  date.  " 

Check  off  of  input  supplied. 

Check  off  of  output  required. 

Security  Classification  Control  Card  data  to  be  supplied 
by  user. 

Copies  required. 

Disposition  of  output . 

Special  instructions. 

b.  Graphic  Processing  Chart  (see  section  2.5). 

2.3  Phasing  (ADP).  This  paragraph  shall  provide  a  schedule  of  acceptable 
phasing  for  each  system  run.  Each  ADP  application  is  subject  to  being 
segmented  into  logical  phases  of  operation.  A  system  run  may  be  phased 
to  permit  manual  or  semi-automatic  checking  of  intermediate  results,  to 
provide  the  user  with  intermediate  results  for  other  purposes,  or  to  permit 
a  logical  break  if  higher  priority  jobs  are  submitted  to  the  ADP  Center. 

The  minimum  division  for  most  applications  would  be  edit;  file  update;  and 
report  preparation.  Job  divisions,  however,’  would  be  restricted  to  specific 
applications  and  should  include  considerations  of  the  time  lapse  required 
for  a  processing  cycle. 
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2  4  Card  Deck  Sequence  This  paragraph  shall  present  an  illustration  of 
the  c^rd  deck  sequence.  Narrative  material  shall  be  included  as  necessary 
»o  explain  details,  constraints,  exceptions,  etc.  concerning  the  assembly 
and  use  cf  the  card  deck.  An  example  follows: 


INPUT  DECK  ASSEMBLY  (EXAMPLE) 

FrUow  ng  is  a  schematic  illustration  of  the  order  of  assembly  of 
an  input  deck  at  run  time: 


Code  43  cards 

^  (k 

v?  required 

"  /43  Code  43 

mmm 

It  iess  ♦han  3  dates. 

^42  Code  42 

■1 

cm’t  Cede  42  card 


L 


f 


Jf< 


L 


C 


Cards 


ummary 
[Format  Cardd 


uff  Control 
Card 


r 


/Call  Tuff  and 
Write  File 

J - n-e 


P 


Job  Card 
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2.  5  Graphic  Processing  Chart  (ADP).  This  technique  has  been  developed 
as  a  metnod  of  requesting  and  controlling  production  processing  operations. 
The  Graphic  Processing  Chart  is  essentially  a  macro  flow  chart  that  has 
been  modified  to  serve  as  a  request  document  for  computer  operations. 

An  example  is  shown  on  the  following  page.  With  the  concurrence  of  the 
data  administrator  (user),  Graphic  Processing  Charts  are  to  be  prepared 
for  each  phase  of  the  system  as  described  in  control  requirement'  'section 
2. 1).  Applications  with  flexibility  of  run  sequence  to  produce  vav.ed  output 

should  be  established  as  options,  with  accompanying  graphics  depicting 

i 

sequence  of  runs  required. 

2.6  Tape  Retention  Schedules  (ADP).  Tape  Retention  Schedules  are  to  be 
developed  in  accordance  with  the  requirements  for  data  retention  of  the 
data  administrator.  It  is  expected  that  due  consideration  will  be  given  to 
this  matter  so  that  the  resulting  schedule  will  reflect  only  those  tapes 
(and  with  realistic  retention  periods)  for  which  a  bona  fide  requirement 
exists.  Tape  storage  facilities  are  limited  and  a  dynamic  system  of  tape 
replacement  and  release  is  necessary. 

Consideration  should  also  be  given  for  temporary  retention  during  pro- 

[ 

cesssing  cycles  to  provide  for  verification  of  output  prior  to  release  of 
tapes,  betckup,  and  requirements  for  alternate  site  storage,  etc.  Basic 
information  required  is  as  follows: 

a.  Project  Number. 

b.  Subsystem  Number  (if  applicable)- 

c.  Tape  Name. 
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GRAPHIC  PROCESSING  CHART  (EXAMPLE 


d.  Run  number  generated.. 

e,  Retention  Schedule  (Classificaticns)  to  Include: 

Release  data  (if  applicable). 

Replacement  instructions. 

Hierarchy  instructions. 

Retention  duration. 

2. 7  File  Querv  Pr  cedures.  This  paragraph  is  to  be  prepared  for 
computer  prefects  with  a  functional  query  retrieval  capability.  The 
instructions  necessary  for  recognition,  preparation,  and  processing  of  a 
query  request  as  -policable  tc  subject  data  base  are  to  be  cited  in  detail. 
The  descriptive  tec  hniques  illustrated  in  Sections  2,  7. 1,  2. 7.  2  and  2.  7.  3 
are  to  be  utilized  as  applicable. 


2.  7, 1  System  Query  Capabilities.  This  pa|agraph  shall  illustrate  in 
tabular  form  »he  preprogrammed  query  capabilities  provided  by  the  system 
with  a  cr«  ss-  reference  fr  a  format  table  coo?  or  identity  (see  example 
bel'  w)  iliustrntif  n  sh*  uld  be  given  to  spow  the  relation  of  a  query 
request  tc  a  specific  querv  format. 


PREPROGRAMMED  QUERY  CAPABILITIES  (EXAMPLE) 


Querv  Format  Table 

All  ships  in  particular  Fleet  A 

Specific  ships  in  particular  Fleet  B 

Units  assigned  h  specific  Task  Force  C 

A/C  Aboard  specific  ship  D 

Ships  with  A  C  ah  ud  E 

Ships  within  a  radius  3c  cation  etc.  '  F 
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2.  7.2  Data  Base  Format.  This  paragraph  shall  illustrate  the  data  base 
format  and  content  (see  example  below).  Indicate,  if  applicable,  data  base 
items  which  are  not  subject  to  query  extraction  and/or  those  data  base 
items  which  should  be  extracted  for  all  queries  whether  or  not  specifically 
requested. 

DATA  RECORD  FORMAT  (EXAMPLE) 


Item  No. 
1 


2 

3 

4 


Item  Name 
Ship/Unit  Name 


Message  DTG 

Fleet/Ocean 

ETA 


WKM 
012  4  0 
1 
2 
3 

4  2  8  4 

5  6  15 

6  15  6 


2.  7. 3  Query  Preparation.  Instructions  are  to  be  provided  for  the  prepara¬ 
tion  of  query  title,  request,  and  output  cards.  The  details  of  query  card 
preparation  in  the  context  of  this  specific  data  base  and  system  retrieval 
capabilities  are  to  be  repeated  as  necessary  in  the  form  of  positive  instruc¬ 
tions,  The  examples  on  the  following  page  present  a  recommended  format 
to  be  prepared  for  each  query  capability  provided.  This  format  will  be 
utilized  by  control  personnel  to  transcribe  planned  queries  into  the  technical 
phrasing  of  the  retrieval  system  and  provide  copy  suitable  for  conversion 
into  punched  cards  and/or  punched  paper  tape. 
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Query  Item  Title 

Query  Designator 
File  Number 
Query  Number 
Security  Classification 
Format  Table  Code 
Sequence  Number 
Fleet 


SUBJECT 

OPERATIONS  MANUAL 


FORMAT  TABLE  A  (EXAMPLE) 
Begin  Card  Cols. 
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1- Q 

2- 01 
4-01 
10-SE 

12- A 

13- A 
14 


Permanent  Coding  app- 

i 

licable  to  Format  Table  A 


Insert  Fleet  code  as  re¬ 
quested  by  query- refer  to 
data  format  for  applicable 
code. 


Query  Item  Title  Begin  Card  Cols. 

Query  Designator  I-Q 

File  Number  2-01 

Query  Number  4  As  applicable 

Security  Classification  10-SE 

Provide  preprinted  form  as  illustrated  above  for  each  query  possibility 
programmed. 


FORMAT  TABLE  B  (EXAMPLE) 
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2.  7.4  Control  Instructions.  Instructions  are  to  be  provided  for  Control 

•>» 

personnel  on  the  sequencing  of  runs  and  the  program  necessary  to  extract 
the  response  to  the  query  request  from  the  data  base.  These  instructions 
shall  include  the  requirements  for  and  the  preparation  of  control  cards  as 
may  be  required  by  the  system  or  functional  programs. 

3.  OPERATING  PROCEDURES 

Section  3  of  the  Operations  Manual  shall  present  the  procedures  and 
materials  required  to  perform  each  of  the  individual  runs,  operations, 
tasks,  etc.  that  comprise  the  system.  The  presentation  of  procedural 
actions  and  responses  required  of  the  operator  in  regard  to  inputs  required, 
machine  indications,  and  outputs  expected  shall  be  made  in  a  logical  manner 
and  shall  follow  the  sequence  normally  required  in  performing  the  run. 

In  addition,  procedures  shall  be  provided  that  cover  the  occurrence  of 
abnormal  or  unexpected  operations. 

3. 1  EAM  Tasks.  EAM  tasks  unique  to  a  particular  system  will  be  pre¬ 
sented.  EAM  tasks  which  are  routine  with  most  systems  will  not  be  in¬ 
cluded.  The  basic  sequence  of  setup- operate-terminate  shall  be  followed 
in  presenting  the  EAM  run  procedures.  Representative  of  the  items  for 
which  detailed  information  is  required  for  each  EAM  run  are  the  following: 

a.  Input  Materials 

Input  data  forms  or  decks  (e.g.,  content,  code,  structuring). 
Output  data  forms  or  cards  (blanks  for  card  punch  or  printer). 
Program  or  format  cards  or  tapes. 
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Control/ Admin  forms  authorizing  the  run. 

Instruction  or  layout  sheets  specifying  what  is  to  be  done  to 
input  data  (keypunching  of  characters  into  specified 
columns  or  fields;  sorting  by  a  particular  item  of  card 
data). 

Sources  of  input  materials  (control  supervisor;  operator  of 
a  prior  run). 

Disposition  of  input  materials  (return  to  control  supervisor; 
excess  forms  to  stockroom;  pass  to  operator  of  a 
succeeding  run). 


b.  Output  Expected 


Specify  the  output(s)  expected  from  the  run. 

Note  any  checks  or  verifications  that  may  be  required. 
Specify  the  disposition  of  the  output  (forward  to  control; 

to  operator  erf  a  succeeding  run).  Note  also  any  require* 
ments  for  binding,  deleaving,  packaging,  labeling,  and 
the  like. 


c.  Procedures  -  Itemize  the  step-by-step  requirements  of  actions, 
indications,  and  responses  for  the  operator  in  setting  up,  opera¬ 
ting,  and  terminating  the  run  (setting  of  switches,  insertion  of 
program  boards,  etc.).  Include,  where  appropriate,  operator 
actions  in  response  to  an  aborted  run  or  an  unsuccessful  run 
(output  not  as  specified)  such  as  restart,  notify  supervisor  or 
EAM  maintenance.  Atthe  tflftcretion  of  the  Project  Leader,  a  flow 
diagram  of  EAM  tasks  may  he  included.  An  example  is  on  the 
following  page. 
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OFFICER  PROMOTION  LIST 


Pre-punched  cards  are  received  from  OPNAV  Communications  for  tapes 
to  be  cut  for  ALNAV  Messages.  THE  SEQUENCE  OF  THE  CARDS  FROM 
OPNAV  SHOULD  NOT  BE  CHANGED,  BECAUSE  OF  PRECEDENCE. 


1.  With  control  panel  wired  as  in 
end.  #1  reproduce  the  cards  from 
OPNAV,  omitting  a  0  and  1  in  cc.  1  of 
alternate  cards.  Reproduce  only  name 
cc.  1-20  into  cc.  8-27.  Be  sure  to 
precede  cards  to  be  reproduced  with  a 
blank  card.  Be  sure  first  card  has 
”0”  in  cc.  1  and  second  has  ”1",  third 
has  "0",  etc.  Label  this  deck  #1. 


2.  There  is  an  alternative  in  step  #2.  . 
The  reproduced  cards  can  be  reproduced 
80-80,  dropping  cc.  1  or  reproduce  with 
the  control  panel  in  step  #1,  using 
OPNAV  cards.  Omit  wiring  for  cc.  1. 
Label  this  deck  #2. 


3.  Take  deck  #2.  Sort  alpha  cc.  8-27 

4.  Sequence  check  on  the  above  field. 
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3.2  Equipment  Configuration.  The  EAM  Units  and  the  I  OP  Units  required 
to  implement  this  operation  shall  be  listed  and  identified.  As  examples: 


a.  EAM  Sorting  Run  (input  data  on  form  sheets). 

Key  Punch  -  (identify). 

Card  Sorter  -  (identify). 

b.  EDP  Card-Tape  Run  (preprocessing  of  data). 

1401  Processor. 

Card  Reader  -  (identify). 

Tape  Adapter  -  (identify). 

Tape  Unit  -  (identify). 


3.3  EDP  Tasks.  The  EDP  tasks  that  the  system  provides  are  performed 
on  the  ADP  facility's  data  processor  with  the  support  of  appropriate 
peripheral  units  which  provide  input,  output,  and  auxiliary  storage.  All 
necessary  procedures  and  input-output  information  shall  be  presented  for 
each  EDP  run  or  operation  of  the  subject  system.  The  runs  delineated  for 
control  and  operator  personnel  may  apply  to  an  auxiliary  data  processor  in 
the  ADP  facility  or  to  a  main  or  primary  processor.  The  scope  and 
content  of  the  information  presented  will  enable  control  personnel  to  specify 
in  detail  the  materials  and  procedures  required  for  the  operator(s)  to 
perform  the  EDP  run  or  job.  Representative  of  the  information  required 
for  each  EDP  run  would  be  the  following: 

a.  Input  Materials  -  The  checklist  items  listed  under  paragraph 

3  l.a.  are  applicable  to  EDP  runs.  In  general,  the  physical  form 
will  be  punched  cards,  paper  or  magnetic  tape,  and  keyboard 
messages.  Functionally  the  inputs  will  represent  a  program  to  be 
loaded  and/or  input  data  (reference -and/ or  current  transactions). 
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Outputs  Expected  -  The  checklist  of  items  under  3.  l.b.  are 
applicable  to  EDP  runs.  In  general,  the  outputs  can  be  produced 
as  punched  cards,  paper  or  magnetic  tape,  hard  copy  printouts,  or 
CRT  and  screen  displays  which  contain  the  information  desired 
from  the  program  run. 

Procedures 

Setup  -  these  procedures  shall  itemize  the  logical  sequence 
of  operator  actions  in  selecting  and  initializing  the  specified 
peripherals  and  the  central  processor  console  so  that  the 
programs  associated  with  the  run  may  be  loaded  and  readied 
for  operation.  On-line  runs  will  have  a  control  program 
assisting  in  setup  procedures  and  communicating  instructions 
to  the  operator  via  the  control  console.  Samples  of  completed 
run  sheets  will  be  included.  The  development  of  individual 
run  sheets  will  be  coordinated  with  the  user  in  order  to 
insure  compatibility  with  existing  user  requirements.  An 
exampjl^  of  a  run  setup  sheet  is  shown  on  the  following  page. 
Operation  -  these  procedures  shall  itemize  the  logical  se¬ 
quence  of  operator  actions  in  loading  the  input  data  (dynamic 
.  .  .  ■  *  -  ' 

and  reference)  for  read- in  to  the  processor  and  initiating  the 

run  at  the  console.  Attention  shall  be  given  to  noting  the 
correct  sequence  or  order  of  reading  of  data  (e.g. ,  control 
cards  for  date,  job  number,  file  ID,  etc.  followed  by  data 
set3  and  end- of- input  cards).  An  illustration  of  card  deck 
sequence  will  also  be  included  here. 
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1401  OPERATING  INSTRUCTIONS  _ 


Project  Number  Program  Name  Program  Number  Run  Number 


Dens 


Label 


Unit 

No. 


rder  of  Input  Sequence 

Cols.  (Data) 


TAPE  INPUT /OUT PUT 


In-  Out- 

Put  Put  Class  Source/Disposition 


READER  INPUT 


NR  Disposition  4 


Forms  Type 


Control  Panel  No. 


PRINTER  INFORMATION 


Printer 

Disposition  Alignment 


Vertical 


Horizontal 


PAPER  TAPE 


Source  Disposition 


Tape  Punch  Level 


O  O 

5  7 


*  =  See  Opr.  Instr. 
X  =  Switch  on 
Blank  =  Switch  Off 


Disposition 


Sense  Switches 


O  O  0  o  o  o  o 

A  B  C  D  E  F  G 


General  Operating  Instructions 


Printer  Comments  1407 


Printer  Comments  1403 


Halts 


Action  to  be  Taken 


RUN  SETUP  SHEET  (EXAMPLE) 
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Input  keyboard  messages  in  on-line  operations  will  provide 

similar  system  direction  by  virtue  of  their  header  informa- 

•I 

tion.  Included  in  this  section  on  Operation  shall  be  applicable 

/  '  . 

information  on  data  processor  -  operator  communications 

that  can  occur  during  the  run.  Specifically,  tabulations  shall 
be  presented  on: 

a.  Error  Messages. 

b.  Program  Normal  Halts. 

c.  Program  Abnormal  Halts. 

The  tabulation  shall  identify  the  output;  its  cause;  its  medium 
(console  typewriter,  card  punch,  printer  or  console  register 
display);  the  response  or  action  required  of  the  operator  and 
any  feedback  or  response  from  the  processor  as  a  result  of 
the  action.  Examples  will  be  given  of  the  formats  of  these 
inputs  and  outputs. 

Termination  -  These  procedures  shall  inform  the  operator  of 
the  sequence  of  actions  that  must  be  followed  in  returning  the 
peripherals  and  processor  to  their  standby  condition  from 
which  setup  procedures  for  the  next  operation  may  proceed. 

4.  NON- ROUTINE  OPERATIONS 

The  purpose  of  Section  4  of  the  Operations  Manual  shall  be  to  provide,  as 
applicable,  control  information  and  operator  procedures  to  cover  emer¬ 
gency  or  non- routine  ADP  operations.  Representative  of  the  situations  that 
may  be  covered  in  the  paragraphs  of  this  section  are  the  following: 

a.  Recovery  from  a  power-off  or  failure  condition. 

b.  Switchover  to  a  redundant  system  or  to  a  standby  system. 

c.  Turnover  to  maintenance  for  system  testing  or  modification. 

d.  Priority  restart  procedures. 
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BIBLIOGRAPHY 

The  bibliography  will  provide  a  list  of  direct  *md  indirect  references  which 
are  worthy  of  note  by  the  readers.  Each  entry  will  contain  Title,  Date, 
Document  Number,  Classification,  Author,  and  Publisher,  if  applicable. 
The  titles  of  books,  papers,  reports  and  pamphlets  will  be  underscored; 
the  titles  of  articles  within  a  publication  will  be  placed  in  quotation  marks. 
The  entries  will  be  arranged  alphabetically  by  author. 
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APPENDIX 

- 

SYSTEM  ABBREVIATIONS,  MNEMONICS,  AND  TERMS 

The  Appendix  will  provide  the  definitions  of  terms  or  phrase  definitions 
which  carry  connotations  unique  to  this  particular  system  or  which  are 
not  sufficiently  standard  as  to  be  adequately  defined  in  standard  diction¬ 
aries.  Item  names  and  location  tags  utilized  by  the  various  programs  of 


the  system  will  specifically  not  be 


included  in  this  Appendix; 


to  be  completely  defined  in  the  body  of  the  document  or  separate  appendices 


these  are 


This  Appendix  is  intended  primarily  to  provide  definitions  of 
found  in  the  documentation  writing  and  not  of  terms  unique  toj 
programs. 


terms  to  be 
specific 
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3.  DOCUMENT  REVIEW 

3.1  Preliminary  Review.  The  preliminary  draft  of  the  proposed  Operations 
Manual  shall  be  given  a  preliminary  review  to  determine  that  the  material 
contained  therein  is  sufficiently  complete  to  warrant  the  preparation  of  a 
final  copy.  Acceptance  or  approval  of  a  preliminary  draft  in  the  course  of 
preparation  of  the  proposed  Operations  Manual  shall  in  no  case  be  construed 
as  a  guarantee  of  acceptance  of  the  final  copy.  The  preliminary  review 
will  include,  but  not  necessarily  be  limited  to,  a  review  of  tho  following 
features: 


a.  Application  or  reference  documents. 

b.  Format  and  arrangements. 

c.  Style  and  phrasing. 

d.  Suitability  of  headings. 

e.  Length  of  paragraphs. 

f.  Physical  length  of  the  document. 

g.  Correctness  of  cross  references. 

h.  Numbering. 

i.  Use  of  abbreviations  and  symbols. 

j.  Grammar. 

k.  Punctuation. 

l.  Technical  accuracy  and  clarity. 

m.  Technical  completeness. 

n.  Absence  of  contractual  information. 
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3.2  Final  Review.  The  Vr-\\  ropy  of  the  proposed  Operations  Manual  shall 
ry.  jtlVhll  it  ihul  review  to  determine  that  the  requirements  of  this  specif ica- 
uon  hAVe  been  satisfied.  Final  review  will  include,  but  not  necessarily  be 
limited  to,  a  review  of  the  features  listed  under  paragraph  3. 1  and  the 
following: 

a.  Quality  of  duplimat. 

b.  Quality  of  typing.  . -  -  —  — 

c.  Reproducibility. 

4.  PROCUREMENT  DATA 

# 

4.1  Ordering  Instructions.  Procurement  documents  concerning  Operations 
Manuals  should  specify  the  following: 

a.  Title,  number,  and  date  of  this  Operations  Manual. 

b.  Applicable  requirements  for  packing,  packaging  and  shipment. 
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1  GENERAL  SPECIFICATION  INFORMATION 


1. 1  Purpose  of  Specification.  This  documentation  specification  provides 
guidance  for  the  preparation  of  Program  Maintenance  Manuals  by  a 
computer  system  developer  when  required  as  a  part  of  a  NAVCOSSACT 
project. 

1.2  Scope  of  Specification 

1.2. 1  General.  The  Program  Maintenance  Manual  shall  include  informa¬ 
tion  starting  wifh  Section  1.  GENERAL  DESCRIPTION  below  in  the  order 
presented  in  this  specification  and  under  the  paragraph  titles  specified. 

All  paragraphs  are  not  applicable  to  every  system  for  which  a  Program 
Maintenance  Manual  is  written  and  portions  not  pertinent  to  a  particular 
system  may  be  designated  not  applicable  by  the  Project  Leader.  At  the 
discretion  of  the  Project  Leader,  this  document  may  be  combined  with  the 
Operations  Manual  and  the  Staff  Manual  into  a  single  volume,  three  part 
document  retaining  the  same  numbering  system  and  presenting  the  same 
iiiformation  as  stated  for  each  individual  document.  Part  1  will  be  the 
Staff  Manual,  Part  2  will  be  the  Operations  Manual  and  Part  3  will  be  the 
Program  Maintenance  Manual.  This  single  volume  will  be  called  the 
Project  Manual. 


1.2.2  Reader  Orientation.  The  Program  Maintenance  Manual  presents 
general  and  applied  information  on  a  specific  system.  It  is  written  for 
programmer  personnel  who  are  part  of  the  user's  organization  and  are 
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responsible  for  the  maintenance  of  the  system  operated  in  the  user's  ADP 
facility.  It  will  be  a  dot. tiled  technical  presentation. 


2  CONTENT  OF  PROGRAM  MAINTENANCE  MANUAL 

The  content  of  the  Program  Maintenance  Manual  shall  be  in  accordance 

with  the  format  on  the  following  pages  through  Appendix  D. 
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1.  GENERAL  DESCRIPTION 


1. 1  Purpose  of  the  Program  Maintenance  Manual.  Paragraph  1. 1  shall 

describe  the  purpose  of  the  Program  Maintenance  Manual.  The  descrip¬ 
tion  will  be  in  accordance  with  the  following  NAVCOSSACT  objective  for 
preparation  of  a  Program  Maintenance  Manual:  j 

I 

! 

Provide  the  maintenance  programmer  personnel  with  the  • 

information  necessary  to  maintain  the  system  effectively. 

•  .  .  ■  t 

) 

1.2  System  Application.  In  general,  non- ADP  terms,  the  purpose  of 
the  system  and  the  functions  it  performs  shall  be  explained.  A  particular 
functional  type  of  system,  for  example,  might  serve  to  control  mission 
activities  by  accepting  specific  inputs  (status  reports,  emergency  condi¬ 
tions),  extracting  items  of  data,  and  deriving  other  items  of  data  in  order 
to  produce  information  for  a  specific  mission's  file  ?nd  for  printout  of 
summary  reports.  These  shall  be  related  to  paragraphs  2.3.3  Specific 
Performance  Requirements,  and  2.3.4,  System  Functions,  of  the  Pre¬ 
liminary  Functional  Description  (PFD). 

1.3  Equipment  Environment.  The  material  in  this  paragraph  shall 
discuss  the  equipment  configuration  and  its  general  characteristics  as 
they  apply  to  the  system. 
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1.4  Program  Environment.  This  paragraph  will  present  the  interactions 
with  support  systems,  within  the  programs  themselves,  and  with  any 
controlling  system. 
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1.5  Conventions.  This  paragraph  will  explain  all  rules,  schemes,  and 
conventions  that  have  been  adopted  for  use  in  the  system.  Information  of 
this  nature  would  include  the  following  items: 

Design  of  mnemonic  identifiers  and  their  application  to  the 
tagging  or  labeling  of  programs,  sub-routines,  records, 
data  fields,  storage  areas,  etc. 

Procedures  and  standards  in  regard  to  flow  charts,  listings,  and 
abbreviations  used  in  statements,  remarks,  and  comments 
appearing  in  charts  and  listings. 

2.  SYSTEM  DESCRIPTION 

The  purpose  of  Section  2  is  to  show  the  structure,  operation,  and  composi¬ 
tion  of  the  system  as  a  set  of  interrelated  programs. 

2. 1  General  Description.  This  paragraph  will  provide  a  comprehensive 
description  of  the  system,  subsystem,  jobs,  etc.  in  terms  of  their  functions 
and  contribution  to  the  system  application.  This  description  will  be 
accompanied  by  a  System  Logic  Chart  in  Appendix  B.  (Ref  NAVCOSSACT 
STD  50-15). 

2.  2  Detailed  Description.  The  purpose  of  this  paragraph  is  to  supply 
details  and  characteristics  of  each  program  that  would  be  of  value  to  a 
maintainer  in  understanding  the  program  and  its  relationship  to  other 
programs.  Special  maintenance  programs  related  to  the  specific  system 
being  documented  will  be  discussed  under  Section  4. 4,  Special  Maintenance 
Programs.  Paragraph  2.  2  will  initially  contain  a  list  of  all  programs  to 
be  discussed  therein,  followed  by  a  narrative  description  of  each  program 
under  separate  paragraphs  starting  with  2.  2. 1  through  2.  2.N.  Information 
of  this  type  is  represented  by  the  following  items: 
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Description  of  program  functions. 

Number  of  program  instructions. 

Data  file  records  used  by  the  program  during  operation. 

Branching  conditions  provided  in  the  program. 

Entry  requirements  concerning  the  initiation  of  the  program. 

Input  data  type  and  location(s)  used  by  the  program  when  its 
operation  begins. 

Exit  requirements  concerning  termination  of  the  program 
operation. 

Communication  or  linkage  to  a  next  logical  program  (operational; 
control). 

Output  data  type  and  location(s)  produced  by  the  program  for  use 
by  the  next  processing  segment  of  the  system. 

Response  to  errors  detected  during  the  program's  input- 
processing-cutput  operations. 

Restrictions  that  have  been  designed  into  the  system  in  respect 
to  the  operation  of  this  program. 
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Permanency  -  note  if  the  program  is  a  normal  link  in  the  cycle 
of  programs  to  be  run  or  will  be  used  under  certain  circumstances 

Storage  -  Specify  the  amount  of  storage  required  to  use  the 
program  and  the  broad  parameters  of  the  storage  locations 
needed. 

Associated  Programs  -  Identify  the  programs  which  can  access 
this  program. 

Restrictions  -  Explain  any  limitations  on  the  use  of  this  program. 

Major  Operations  -  The  major  operations  of  each  program  will 
also  be  described.  The  description  shall  be  referenced  to  the 
System  Logic  Chart(s)  in  Appendix  B  for  the  program  being 
discussed.  This  chart  will  show  the  logical  flow  of  operations 
such  as  read  an  input,  access  a  data  record,  major  decision, 
and  print  an  output  which  would  be  represented  by  segments  or 
sub-programs  within  the  program. 

Minor  Operations  -  The  minor  operations  are  the  logical  series 
of  operations  performed  by  the  program  in  order  to  realize  the 
major  operations.  A  Program  Logic  Chart(s)  will  be  provided 
in  Appendix  C  for  each  of  the  program's  major  steps  (Ref 
NAVCOSSACT  STD  50-15).  Each  step  will  be  broken  down  into 
its  logical  details.  Program  Logic  Chart(s)  will  be  referenced 
to  the  block  or  symbol  it  represents  on  the  System  Logic  Chart. 
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3.  INPUT/OUTPUT  DESCRIPTIONS 
The  purpose  of  Section  3  of  the  manual  shall  be  to  provide  information  on 
the  structure  and  composition  of  the  system  inputs  and  outputs. 

3.1  General  Description.  This  paragraph  shall  provide  a  general  presenta¬ 
tion  of  the  inputs  and  outputs  in  regard  to  scope  and  the  variety  of  informa¬ 
tion  available  in  support  of  the  system  and  maintained  by  the  system. 

3.2  Characteristics.  The  following  types  of  information  shall  be  provided 
in  this  paragraph  including  all  of  the  information  on  the  nature  and  content 
of  each  of  the  Input/Output  elements  required  by  the  maintainer. 

Identification  -  Name  and  mnemonic  reference  of  the  component 
(e.  g. ,  data  base). 

Function  -  Explain  the  use  of  the  element  in  the  system. 

Content  -  Describe  the  kind  of  data  it  holds.  This  may  be  opera¬ 
tional  data  (input  data;  output  information;  reference  data)  or 
internal  data  such  as  results  of  intermediate  processing,  or 
directory  information  (routing/linkage  tables)  that  enables  a 
program  to  locate  other  records  or  to  communicate  with  other 
programs. 
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Permanency  -  Note  if  the  element  contains  parametric  data  that 
a  program  can  reference  but  may  not  change  or  dynamic  data 
which  can  be  changed  or  updated  during  system  operation. 

Indicate  if  the  change  is  periodic  or  random  as  a  function  of 

/ 

Input  data. 

Storage  -  Specify  the  location(s)  in  which  the  element  is  held 
(e.  g. ,  tape;  drum;  core)  and  the  amount  of  storage  required. 

Associated  Programs  -  Identify  the  programs  which  can  access 
this  element  during  their  operation.  Indicate  if  the  program  only 
reads  data  or  may  also  write  new  data  into  the  record.  Explain 
also  how  the  program  locates  the  element  (e.g. ,  table  look  up; 
index  register). 

Restrictions  -  Explain  any  limitations  on  the  use  of  this  element 
by  the  programs  in  the  system. 

3.3  Organization  and  Detailed  Description  of  Input/Outputs.  The  purpose 
of  this  paragraph  shall  be  to  define  the  internal  structure  of  the  input- 
outputs  (an  example  of  each  input/output  will  be  listed  as  will  its  associated 
components  such  as  records  and  tables).  The  layouts  of  each  Input/Output 
element  (e.g. ,  data  base)  will  be  described,  accompanied  by  appropriate 
explanatory  details.  The  following  items  indicate  the  type  of  information 
desired: 
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Layout  -  show  the  structure  of  the  subject  record. 

Sections  -  note  if  the  physical  record  is  a  logical  record  or  one  of 
several  that  constitute  the  complete  logical  record.  Identify  the 
record  parts  such  as  header  or  control  segments  and  the  body  of 
the  record. 

Fields  -  Identify  each  field  of  data  provided  in  the  record  structure 
and  explain  its  purpose. 

Tags/Labels  -  Indicate  the  tag  or  label  assigned  to  reference 
each  field  of  data. 

Size  -  Indicate  the  length  and  number  of  bits/characters  comprising 
each  data  field. 

Range  -  Indicate  the  range  of  acceptable  values  for  the  field  entry, 
if  a  numeric. 

Expansion  -  Note  provisions,  if  any,  for  adding  additional  data 
fields  to  the  record. 

3.4  Examples  of  Inputs/Outputs.  This  paragraph  will  give  examples  of 
(all)  input/output  elements  associated  with  the  system. 
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4.  PROGRAM  MAINTENANCE  PROCEDURES. 

Section  4  of  the  manual  shall  provide  all  information  necessary  for  the 
programmer  to  maintain  the  programs  that  comprise  the  system. 

4. 1  Input-Output  Requirements.  Include  in  this  paragraph  the  require¬ 
ments  concerning  the  equipment  and  materials  needed  to  support  a  mainte¬ 
nance  task.  Materials  may,  for  example,  include  card  decks  for  loading 

a  maintenance  program  and  the  inputs  which  represent  the  changes  to  be 
made. 

* 

4.2  Procedures.  The  procedures  to  be  presented  in  a  step-by-step  manner 
shall  show  the  maintainer  the  method  of  preparing  the  inputs  such  as  the 
keypunching  and  structuring  of  an  input  and  sequencing  of  inputs.  Also,  the 
operations  or  steps  to  be  followed  in  setting-up,  running  and  terminating 
the  maintenance  task  on  the  machine  shall  be  given. 

4.3  Verification  This  paragraph  will  include  those  requirements  (e.  g. , 
test  data)  and  procedures  necessary  to  check  out  the  performance  of  the 
program  section  following  Its  modification. 


4.4  Special  Maintenance  Programs.  This  paragraph  shall  contain  an 
inventory  and  description  of  the  uses  of  any  special  programs  to  maintain 
the  system. 

4.  5  Other  Special  Maintenance  Procedures.  This  paragraph  shall  contain 
any  special  procedures  used  by  the  maintainer  which  have  nc  been 
delineated  in  Section  4,  PROGRAM  MAINTENANCE  PROCEDURES. 
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Specific  information  that  may  be  appropriate  for  presentation  would  include: 

Requirements,  procedures  and  verification  methods  required  to 
maintain  the  system  input- output  elements  (data  base). 
Requirements,  procedures  and  verification  methods  required  to 
perform  a  Library  Maintenance  System  run. 

4. 6  Listings.  Under  separate  cover  as  Appendix  D  to  this  document  will 
be  a  listing  of  coding  statements  written  in  symbolic  programming  language 
or  a  higher  level  language.  Annotations  shall  be  provided  to  introduce 
components  of  the  system  and  clarifying  remarks  and  comments  appropriate 
to  particular  instructions  shall  be  made. 
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The  bibliography  will  provide  a  list  of  direct  and  indirect  references  which 
are  worthy  of  note  by  the  readers.  Each  entry  will  contain  Title,  Date, 
Document  Number  and  Classification,  Author,  and  Publisher  if  applicable. 
The  title  of  books,  papers,  reports,  and  pamphlets,  will  be  underscored; 
the  titles  of  articles  within  a  publication  will  be  placed  in  quotation  marks. 
The  entries  will  be  arranged  alphabetically  by  author. 
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APPENDIX  A 

SYSTEM  ABBREVIATIONS,  MNEMONICS,  AND  TERMS 

The  Appendix  will  provide  the  definitions  of  terms  or  phrase  definitions 
which  carry  connotations  unique  to  this  particular  system  or  which  are 
not  sufficiently  standard  as  to  be  adequately  defined  in  standard  diction¬ 
aries.  Item  names  and  location  tags  utilized  by  the  various  programs  of 
the  system  will  specifically  not  be  included  in  this  Appendix;  these  are 
to  be  completely  defined  in  the  body  of  the  document  or  separate  appendices. 
This  Appendix  is  intended  primarily  to  provide  definitions  of  terms  to  be 
found  in  the  documentation  writing  and  not  of  terms  unique  to  specific 
programs. 
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APPENDIX  B 
SYSTEM  LOGIC  CHARTS 

Appendix  B  shall  contain  the  ordered  set  of  charts  which  show  the  major 
functions  of  the  system.  The  charts  shall  support  the  narrative  description 
of  the  system's  major  operation  given  in  the  Program  Maintenance  Manual 
under  paragraph  2.2  Detailed  Description.  System  Logic  Charts  will  be 
prepared  in  accordance  with  Standard  50-15 


NUMBER 


40-45 


PAGE 

OF 

16 

20 

NAVCOSSACT 

STANDARDS 


SUBJECT 

PROGRAM 

MAINTENANCE  MANUAL 

APPENDIX  C 

PROGRAM  LOGIC  CHARTS 

Appendix  C  shall  contain  the  ordered  sets  of  charts  which  show  the  logical 
series  of  detailed  operations  that  are  performed  under  each  major  function 
of  the  system.  A  set  of  charts  shall  be  associated  with  each  major  opera¬ 
tion  of  the  system  shown  in  Appendix  B,  System  Logic  Charts.  The  charts 
shall  support  the  description  given  in  the  Program  Maintenance  Manual 
under  Paragraph  2.2  Detailed  Description.  Program  Logic  Charts  will  be 
prepared  in  accordance  with  Standard  50-15. 
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APPENDIX  D 
LISTINGS 


Appendix  D  shall  contain  under  separate  cover  the  system's  listing  uf 
coding  statements  written  in  symbolic  programming  language  or  a  higher 
level  language.  The  listing  shall  include  annotations  that  establish  associ 
ations  with  the  system  flow  charts  provided  in  Appendices  B  and  C. 
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3.  DOCUMENT  REVIEW 


3. 1  Preliminary  Review.  The  preliminary  draft  of  the  proposed  Program 
Maintenance  Manual  shall  be  given  an  appropriate  preliminary  review  to 
determine  that  the  material  contained  therein  is  sufficiently  complete  to 
warrant  the  preparation  of  a  final  copy.  Acceptance  or  approval  of  a 
preliminary  draft  in  the  course  of  preparation  of  the  proposed  Program 
Maintenance  Manual  shall  in  no  case  be  construed  as  a  guarantee  of 
acceptance  of  the  final  copy.  The  preliminary  review  will  include,  but 
not  necessarily  be  limited  to,  a  review  of  the  following  features: 


a.  Application  of  reference  documents 

b.  Format  and  arrangements 

c.  Style  and  phrasing 

d.  Suitability  of  headings 

e.  Length  of  paragraphs 

f.  Physical  length  of  the  document 

g.  Correctness  of  cross  references 

h.  Numbering 

i.  Use  of  abbreviations  and  symbols 

j.  Grammar 

k.  Punctuation 

l.  Technical  accuracy  and  clarity 

m.  Technical  completeness 

n.  Absence  of  contractual  information 
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3.2  Final  Review.  The  final  copy  of  the  proposed  Program  Maintenance 
Manual  shall  be  given  a  final  review  to  determine  that  the  requirements 
of  this  specification  have  been  satisfied.  Final  review  will  include,  but 
not  necessarily  be  limited  to,  a  review  of  the  features  listed  under 
preliminary  review  and  the  following: 


a.  Quality  of  duplimat 

b.  Quality  of  typing 

c.  Reproducibility 


4.  PROCUREMENT  DATA 

4.1  Ordering  Instructions.  Procurement  documents  concerning  Program 
Maintenance  Manuals  should  specify  the  following: 


a.  Title,  number  and  date  of  the  Program  Maintenance  Manual 

b.  Applicable  requirements  for  packing,  packaging  and  shipment 
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1.  GENERAL  SPECIFICATION  INFORMATION 


l 


i 


1. 1  Purpose  of  Specification.  This  documentation  specification  provides 
guidance  for  the  preparation  of  Acceptance  Test  Plans  by  a  computer  sys¬ 
tem  developer  when  required  as  a  part  of  a  NAVCOSSACT  project. 


1.2  Scope  of  Specif ’cation 

1.2. 1  General.  Each  Acceptance  Test  Plan  shall  include  information 
starting  with  Section  1  GENERAL  below  in  the  order  presented  and  under 
the  paragraph  titles  specified.  All  paragraphs  are  not  applicable  to  every 
system  for  which  an  Acceptance  Test  Plan  is  written  and  portions  not  per¬ 
tinent  to  a  particular  system  may  be  designated  not  applicable  by  the  Pro¬ 
ject  Leader. 


1.2.2  Reader  Orientation.  The  Acceptance  Test  Plan  is  primarily  a  tool 

for  directing  the  implementation  of  a  test. .  Those  parts  of  the  document 

•» 

directed  toward  the  staff  personnel  are  to  be  presented  in  non-technical 
language  and  those  parts  of  the  document  directed  toward  the  operations 
personnel  are  to  be  presented  in  the  language  of  the  operations  center. 

2.  CONTENT  OF  ACCEPTANCE  TEST  PLAN 

The  content  of  the  Acceptance  Test  Plan  will  be  in  accordance  with  the 
format  on  the  following  pages. 
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1.  GENERAL 

1. 1  Purpose  of  Acceptance  Test  Plan.  Parag  raph  1. 1  shall  describe  the 
purpose  of  the  Acceptance  Test  Plan.  The  description  will  be  in  accord¬ 
ance  with  the  following  NAVCOSSACT  objectives  for  preparation  of  an 
Acceptance  Test  Plan: 


a.  Provide  guidance  for  the  management  and  technical  effort 
necessary  throughout  the  test  period,  from  preparation  through 

*  the  Test  Analysis  Report. 

b.  Establish  a  comprehensive  test  plan  and  communicate  to 
NAVCOSSACT  and  user  management  and  user  operational 
personnel  extent  of  tests  deemed  necessary  to  provide  a  basis 
for  system  acceptance  by  the  user. 

' 

c.  Communicate  to  appropriate  user  personnel  the  equipment  and 

organizational  requirements  necessary  for  testing  the  system. 

»  i  . 

d.  For  support  systems,  provide  for  ADP  operations  center 
evaluation  using  functional  data. 

j 

e.  Establish  tjhe  detailed  content  of  the  required  testing. 

f .  Provide  th4  methodology  of  the  testing  to  be  performed. 

i 

g.  Provide  a  written  record  of  the  actual  inputs  to  the  test  and  the 
expected  outputs. 

h.  Establish  a  detailed  scenario  to  permit  execution  of  the  test 
(exercise)  by  user  staff  and  operator  personnel. 

i.  Specify  test  details  to  exercise  limits  and  critical  capabilities 
of  the  system. 


1.2  Project  Reference.  This  paragraph  shall  identify  the  system  by  its 
formal  title  and  number  and  briefly  indicate  the  type  of  system  involved, 
scale  of  operation,  usage  and/or  users,  and  the  relationship  to  other 
systems.  Emphasized  will  be  any  distinguishing  features  of  the  system. 
The  organization  which  will  conduct  testing  of  the  system  will  be  indicated. 
This  paragraph  will  also  identify  the  project  sponsor  and  user(s). 

1.3  Project  Impacts.  Paragraph  1. 3  shall  cite  any  impacts  which  the 
test  or  operation  of  the  system  will  impose  on  equipment,  personnel,  or 
operating  procedures. 

1.3. 1  Software.  This  paragraph  shall  list. the  software  packages  used 
during  and  in  support  of  the  test  which  are  not  a  part  of  the  system  under 
test. 

1.3. 2  Test  Site.  This  paragraph  shall  indicate  the  physical  location(s) 
at  which  the  test(s)  is  to  take  place,  the  date(s),  and  the  participating 
organizations. 

1.3.3  Test  Milestone  Chart.  Paragraph  1.3.3  shall  provide  a  horizontal 
bar  type  chart  to  depict  the  activities  and  events  below.  This  chart  will  be 
in  chronological  order  with  supporting  narrative  as  necessary. 

<  * 

a.  Overfall  on-feite  test  period  and  portions  of  period  assigned  to 
major  portions  of  test. 

b.  Pre-test  on-site  period  required  for  system  debugging,  orienta¬ 
tion,  and  familiarization. 
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c.  Period  assigned  for  the  collection  of  data  base  values,  input 
values,  and  other  operational  data  required  for  system  test. 

d.  Period  assigned  for  user  orientation  and  familiarization  with 
system  documentation. 

e.  Period  assigned  for  compliance  with  any  special  test  require¬ 
ments  of  a  particular  user. 

f.  Periods  assigned  for  preparation,  review,  and  approval  of  the 
Test  Analysis  Report. 

1.3.4  Personnel  Requirements.  This  paragraph  shall  provide  a  horizontal 
bar  type  chart  to  depict  the  number  and  period  of  use  of  each  skill  type 
required  for  the  entire  test  period(s).  It  will  indicate  special  require¬ 
ments  such  as  multi- shift  operation,  and  assignment  or  retention  of  key 
skills  to  insure  continuity  and  consistency  in  extensive  test  programs. 

1.3.5  Equipment  Requirements.  This  paragraph  shall  provide  a  hori¬ 

zontal  bar  type  chart  to  depict  the  period  of  usage,  and  quantity  required, 
of  each  item  of  equipment  employed  throughout  the  test  period,  including 
test  data  reduction  equipment.  I 

1.4  Applicable  Documents.  Paragraph  1.4  shall  itemize  by  document 
title  and  number  all  documentation  specially  produced  for  the  project. 
Include  any  other  documentation  describing  systems  or  procedures  which 
supplement  or  provide  for  interaction  with  the  subject  system  during  the 
course  of  normal  operation  or  at  any  point  in  the  test  phase.  Assign  a 
separate  identifier  to  each  itemized  document  to  facilitate  reference  to  it 
in  subsequent  sections  of  the  Plan. 
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1.  5  Test  Materials.  Paragraph  1.  5  shall  itemize  the  articles  and 
apparatus  associated  with  the  conduct  of  test.  All  items  not  deliverable 
as  part  of  the  operational  system  should  be  included  under  separate 
heading  for  clear  identification.  Examples  of  test  materials  follow: 

a.  Data  base  card  decks/tapes  identified  by  file  type  and  record 
size. 

b.  Input  card  deck/tapes  identified  by  input  type,  test  sequence 
usage,  and  record  size. 

c.  Support  programs  in  card/tape  form  identified  by  type  and 
record  size. 

d.  Test  control  programs  or  other  special  test  programs  in  card/ 
tape  form  identified  by  type  and  record  size. 

e.  Test  worksheets  and  other  forms  and  instructions  specifically 
prepared  to  control  and  expedite  the  test  activity,  identified  by 
type  and  quantity. 

f.  Apparatus  required  during  or  in  support  of  the  test,  which  is  not 
normally  part  of  the  equipment  configuration  or  deliverable  as 
part  of  the  system.  Apparatus  would  include  extra  peripherals 
(tape  drives,  printers,  plotters),  test  message  generators,  test 
timing  devices,  test  event  recorders.  Such  apparatus  will  be 
identified  by  name,  type,  and  quantity  required. 

2.  SYSTEM  TEST  REQUIREMENTS 


2. 1  General  Requirement.  This  paragraph  shall  provide  a  general 
statement  of  what  is  to  be  demonstrated  by  the  test.  It  will  relate  this 
to  the  Project  Request  and  any  modifications  thereof. 
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2.2  Specific  Requirements.  Paragraph  2.2  shall  list  the  individual 
requirements  to  be  demonstrated  by  the  test  as  derived  from  the  specific 
performance  requirements  (Paragraph  2.3.3)  in  the  Preliminary  Functional 

Description. 

3.  SYSTEM  TEST  METHODS  AND  CONSTRAINTS 

3. 1  System  Test  Methods 

3.1.1  System  Test  Conditions.  This  paragraph  shall  indicate  whether 
the  system  test  is  to  be  made  using  the  normal  system  inputs  (type, 
magnitude,  or  frequency)  and  data  base  or  whether  a  special  set  of  exer¬ 
cise  inputs  and  exercise  data  base  is  to  be  used. 

3.1.2  System  Test  Means  of  Control.  This  paragraph  shall  indicate 
whether  test  is  to  be  controlled  by: 

a.  Manual  Means.  Manual  insertion  of  necessary  inputs  and  manual 
control  of  test  sequence. 

b.  Semi-automatic  Means.  Manual  insertion  of  necessary  inputs 
and  automatic  (test  program)  control  of  test  sequence. 

c.  Automatic  Means.  Preparation  and  use  of  a  special  test  program 
to  provide  necessary  inputs,  conduct  tests,  monitor  and  record 
test  results. 
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3. 1.3  Extent  of  System  Test.  Paragraph  3. 1.3  shall  indicate  the  extent 


of  the  testing  to  be  employed.  Where  total  testing  is  not  to  be  employed, 


there  will  be  presented  the  test  requirements  either  as  a  percentage  of 


some  well  defined  total  quantity  or  as  a  number  of  samples  of  discrete 


operating  conditions  or  values.  Also  indicated  will  be  the  rationale  for 
adopting  limited  testing. 


3.1.4  System  Test  Sequence 

3. 1.4. 1  Test  Progression.  In  cases  of  progressive  or  cumulative  tests, 
there  will  be  indicated  the  manner  in  which  progression  is  made  from  one 
test  to  another,  such  that  the  cycle  of  activity  for  each  test,  as  described 
in  Section  6,  is  completely  accomplished. 

~  i.4.  2  Test  Evaluation.  This  paragraph  will  indicate  whether  test 
steps  are  to  be  performed  without  interruption  for  evaluation  or  whether 
each  step  is  to  be  evaluated  before  testing  continues. 


3.1.5  Data  Recording.  Paragraph  3.1.5  shall  indicate  data  recording 
requirements  including  those  data  types  not  normally  recovered  from 
system  operation.  Data  recording  is  to  include: 

a.  I/O  Events.  Time  ordered  records  of  I/O  activity  to  explicitly 
or  implicitly  correlate  interaction. 

b.  Test  Points.  Time  ordered  records  of  data  values  or  system 
condition  at  selected  points  within  or  peripheral  to  the  operating 
system. 
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c.  Data  Dumps.  Time  indexed  records  of  data  as  stored  at  selected 
storage  locations  within  the  system  at  selected  points  in  time, 
or  as  a  consequence  of  selected  system  operations. 

3.2  System  Test  Constraints.  Paragraph  3.  2  shall  indicate  the  anticipated 
limitations  imposed  on  the  acceptance  test  due  to  system  or  test  conditions, 
such  as  limitations  on  timing,  interfaces,  equipment,  personnel,  and 
data  base. 

4.  SYSTEM  TEST  EVALUATION 

4. 1  Test  Data  Criteria.  Paragraph  4. 1  shall  describe  the  rules  by  which 
test  results  will  be  evaluated,  viz: 

a.  Tolerances.  Range  over  which  a  data  value  output  by  a  system 
performance  parameter  can  vary  and  still  be  considered  acceptable. 

b.  Samples.  The  minimum  number  of  combinations  or  alternatives 
of  input  conditions  and  output  conditions  that  can  be  exercised  to 
constitute  an  acceptable  test  of  the  parameters  involved. 

c.  Counts.  The  maximum  number  of  interrupts,  halts  or  other  system 
breaks  which  may  occur  due  to  non-test  conditions. 

4.  2  Test  Data  Reduction.  Paragraph  4.  2  shall  describe  the  technique  to 
be  used  for  manipulation  of  the  raw  test  data  into  a  form  suitable  for 
evaluation.  The  available  techniques  would  include: 
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a.  Manual.  Manual  collection  and  collation  of  system  test  outputs 
into  test  sequence  order  followed  by  visual  inspection  of  the 
results. 


b.  Semi-automatic.  Automatic  inspection  of  test  results  as  ob¬ 
tained  by  data  recording  means  using  a  test  data  reduction 
program,  followed  by  manual  (visual) inspection  of  selected 
test  results  which  do  not  lend  themselves  to  complete  reduction 
by  automatic  means. 

c.  Automatic.  Automatic  inspection  of  test  results  specially  re¬ 
corded  for  manipulation  by  the  test  data  reduction  program.  1 
Test  results,  as  recorded,  include  all_  items  of  test  significance. 
The  test  data  reduction  program  contains  an  image  of  correct 
data  outputs  for  an  item  by  item  comparison  of  data  and  pro¬ 
vides  a  summary  of  an  evaluated  test  as  output. 

4.  3  Test  Analysis  Report.  Paragraph  4.  3  shall  indicate  that  a  test  re¬ 
port  shall  include  all  tests  conducted  on  the  system  (see  Section  7).  It 
will  be  stated  that  the  report  is  to  ilescribe  the  entire  results  of  each  test 
and  provide  emphasis  on  those  areas  where  a  difference  in  test  and  act¬ 
ual  conditions  applies. 

5.  TEST/FUNCTION  RELATIONSHIPS 

* 

5. 1  System  Functions.  Paragraph  5. 1  shall  provide  a  detailed  list  of  the 
system  functions  which  will  be  exercised  in  the  course  of  over-all  sys¬ 
tem  testing.  This  list,  as  derived  from  the  Preliminary  Functional  Des¬ 
cription  document  (Section  2,  3. 4),  must  be  ordered  in  a  manner  which 
relates  the  system  functions  into  the  system  test  requirements  of  Section  2. 
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5. 2  Test/Function  Relationships.  Paragraph  5.  2  shall  provide  a  list  of 
tests  which  taken  as  a  whole  constitute  the  overall  test  activity.  It  will 
also  provide,  as  applicable,  a  Function-Test  Matrix  Chart  summarizing 
theover-all  allocation  of  system  functions  to  tests.  The  matrix  shall  show 
the  tests  as  rows,  intersected  by  system  functions  as  columns.  Within 
the  cell  structure  so  formed,  those  functions  tested  by  each  test  should 
be  indicated  (X- symbol). 

6.  TEST  DESCRIPTION 

A  decimal  subdivision  of  Section  6  shall  be  used  to  describe  each  test  as 
shown  in  Section  6.1. 

6. 1  Test  (Identify) 

6. 1. 1  Test  Inputs.  This  paragraph  shall  list  the  input  or  inputs  to  the 
test  with  their  associated  data  characteristics.  Data  characteristics  would 
include: 

a.  Type  of  input  (data,  elements,  command  instruction). 

b.  Transfer  (data  rate,  volume,  period). 

6. 1. 2  Test  Outputs.  This  paragraph  shall  list  the  output  or  outputs  from 
the  test  with  their  associated  data  characteristics.  Data  characteristics 
would  include: 

a.  Type  of  output  (data  presentation,  status  indication). 

b.  Transfer  (data  rate,  volume,  period). 
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6.1.3  Test  Conditions.  This  paragraph  shall  provide  a  statement  of 
conditions  which  exist  within  the  test  or  as  part  of  the  input  or  output  to 
the  test.  Conditions  would  include: 
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a.  Setting  of  controlling  parameters  fd£  the  test  (minimums, 
maximums,  thresholds). 

b.  Enabling  conditions  for  receipt  or  output  of  data. 

c.  Priority  conditions  for  processing  of  data  (function  priorities, 
rystem  mode  priorities). 


6.1.4  Sy*  Jer.i  Conditions.  This  paragraph  shall  provide  a  statement  of 
conditions  which  exist  within  the  system  prior  to  test.  Conditions  would 

i 

include: 


a.  Availability  of  file  data  types  and  elements. 

b.  Availability  of  data,  control  and  status  messages  from  interacting 
functions  not  under  test. 

c.  Mode  of  system  operation  (normal,  emergency). 

6. 1.  5  Test  Control 

6. 1.  5. 1  Input  Data.  This  paragraph  will  describe  the  manner  in  which 
input  data  is  controlled  in  order  to: 

a.  Test  system  with  a  minimum  number  of  data  types  and  values. 
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b.  Exercise  system  with  a  range  of  bona  fide  data  types  and 
values  which  test  for  overload,  saturation,  and  other  worst  case 
effects. 

c.  Exercise  system  with  bogus  data  types  and  values  which  test 
for  rejection  of  irregular  inputs. 

6. 1.  5. 2  Input  Commands.  This  paragraph  shall  describe  the  manner 
in  which  input  commands  are  used  to  control: 

a.  Initialization  of  test. 

b.  Halt  or  interrupt  of  test. 

c.  Repeat  of  unsuccessful  or  incomplete  test. 

d.  Alternate  modes  of  operation  as  required  by  test. 

e.  Termination  of  test. 

6. 1.  5. 3  Output  Data.  This  paragraph  shall  describe  the  manner  in  which 
output  data  is  controlled  in  order  to: 

a.  Detect  occurrence  (or  ultimate  non-occurrence)  of  output  data 
(as  event)  for  indication  of  test  completion. 

b.  Record  or  identify  permanent  location  of  output  data  (in  entirety) 
for  indication  of  test  performance. 

c.  Evaluate  output  as  basis  for  continuation  of  test  sequence. 

d.  Evaluate  test  output  against  required  output  to  assess  performance 
of  test. 
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6. 1. 5.4  Output  Notification.  This  paragraph  shall  describe  the  manner 
in  which  output  notifications  (messages  output  byjthe  system  concerning 
status  or  limitations  on  internal  performance)  else  controlled  in  order  to: 

a.  Indicate  readiness  for  test  (normal  operation  condition). 

b.  Provide  indications  of  irregularities  in  input  test  data  or  test 
data  base  due  to  intentional  or  unintentional  test  procedures. 

c.  Provide  indications  of  irregularities  in  internal  operations  on 
test  data  due  to  intentional  or  unintentional  test  procedures. 

d.  Provide  indications  on  the  control,  status,  and  results  of  test 
as  available  from  auxiliary  test  supervisor  program  (if  used). 

,  • 

7.  SYSTEM  TEST  PROCEDURE 

This  Section  shall  contain  the  step-by-step  procedures  to  accomplish  each 
test  of  the  system.  Each  step  is  assigned  a  test  step  number  and  this 
number  along  with  critical  test  data  and  test  procedure  information  is 
tabulated  onto  a  test  procedure  form  for  test  control  and  recording  of  test 
results. 
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7. 1  Test  Set-Up.  Paragraph  7. 1  shall  itemize  the  activities  associated 
with  set-up  of  the  computer  facilities  to  conduct  the  test.  Set-up  activities 
will  encompass  all  routine  machine  activities  from  power  on  through 
console  set-up  to  card/tape  read- in.  This  paragraph  shall  include 
distribution  of  test  documents,  worksheets,  and  other  forms. 


SUBJECT 


NAVCOSSACT 

STANDARDS 


ACCEPTANCE 
TEST  PLAN 


40-50 


7.2  Test  Initialization.  Paragraph  7.  2  shall  itemize  in  test  sequence 
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order,  the  activities  associated  with  establishing  the  conditions  of  the 


first  test  starting  with  the  equipment  in  the  set-up  condition.  Initializa¬ 
tion  would  accomplish: 


a.  Read-out  of  control  function  locations  and  critical  data  from 
indicators  and  storage  locations  for  reference  purposes. 

b.  Setting  or  synchronizing  time  dependent  elements  in  system. 

c.  Queuing  of  data  input  values  for  first  test. 

d.  Queuing  of  test  support  programs  if  used. 

e.  Coordination  of  personnel  actions  associated  with  test. 


7.3  Test  Steps.  Paragraph  7.3  shall  itemize  the  test(s)  into  test  steps 
in  test  sequence  order.  It  shall  also  include  special  operations,  viz: 


a.  Visual  inspection  of  test  conditions.  » 

b.  Data  dumps. 

c.  Instructions  for  data  recording. 

d.  Modifications  of  data  base. 

e.  Interim  evaluation  of  test  results. 

7. 4  Test  Termination.  Paragraph  7. 4  shall  itemize  in  test  sequence 
order,  the  activities  associated  with  termination  of  the  test,  viz: 

a.  Read-out  of  critical  data  from  indicators  and  location  for 
reference  purposes. 

b.  Termination  of  operation  of  time  sensitive  test  support  programs 
and  test  apparatus. 

c.  Collection  of  system  and  operator  records  of  test  results. 
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APPENDIX 

STATEMENT  OF  PRE-TEST  ACTIVITY 

The  Appendix  shall  provide  a  description  of  the  testing  completed  as  part 
of  the  system  development  activity.  This  may  be  provided  in  the  form  of 
a  listing  of  the  elements  in  the  Program  and  Subsystem  Specifications 
against  which  the  program  operation  has  been  explicitly  checked.  The 
description  should  include  any  significant  comments  on  the  operation  of 
the  individual  programs  or  program  subsystems  which  could  affect  test  or 
operation  of  the  system. 
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1.  GENERAL  SPECIFICATION  INFORMATION 

1. 1  Purpose  of  Specification.  This  documentation  specification  provides 

guidance  for  the  preparation  of  Acceptance  Test  Analysis  Reports  by  a 
computer  system  developer  when  required  as  a  part  of  a  NAVCOSSACT 
project. 

1.2  Scope  of  Specification 

1. 2. 1  General.  Each  Acceptance  Test  Analysis  Report  shall  include  infor¬ 
mation  starting  with  Section  1  GENERAL  below  in  the  order  presented  and 
under  the  paragraph  titles  specified.  All  paragraphs  are  not  applicable  to 
every  system  for  which  -n  Acceptance  Test  Analysis  Report  is  written  and 
portions  not  pertinent  to  a  particular  system  may  be  designated  not  appli¬ 
cable  by  the  Project  Leader. 

1.  2.  2  Reader  Orientation.  The  Acceptance  Test  Analysis  Report  has  the 
primary  purpose  of  describing  the  status  of  the  system  after  test.  It  also 
provides  a  presentation  of  deficiencies  for  review  by  staff  and  management 
personnel.  Therefore,  the  document  should  be  prepared  in  non-technical 
language. 


2.  CONTENT  OF  ACCEPTANCE  TEST  ANALYSIS  REPORT 

The  content  of  the  Acceptance  Test  Analysis  Report  shall  be  in  accordance 

with  the  format  on  the  following  pages. 
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1.  GENERAL 

1. 1  Purpose  of  Acceptance  Test  Analysis  Report.  Paragraph  1. 1  shall 
describe  the  purpose  of  the  Acceptance  Test  Analysis  Report.  The  de¬ 
scription  will  be  in  accordance  with  the  following  NAVCOSSACT  objectives 
for  preparation  of  an  Acceptance  Test  Analysis  Report: 

a.  Provide  in  writing  the  results  of  the  acceptance  test. 

b.  Provide  a  basis  for  allocating  responsibility  for  deficiency 
correction  and  follow-up. 

c.  Provide  a  basis  for  preparation  of  NAVCOSS ACT's  statement 
of  completion. 

d.  Establish  user  confidence  in  the  operation  of  the  system. 

1.2  Project  Reference.  Paragraph  1.2  shall  state  the  project  title  and 
number  and  provide  a  brief  summary  of  the  project  objectives.  This 
paragraph  will  also  identify  the  project  sponsor  and  user(s). 

1.3  Applicable  Documents.  Paragraph  1.3  shall  provide  a  list  of  applicable 
documents  by  number  and  title.  This  paragraph  will  include  at  least  the 
following  when  applicable: 

Preliminary  Functional  Description 
Staff  Manual 
Operations  Manual 
Acceptance  Test  Plan 
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2.  TEST  ANALYSIS 
A  decimal  subdivision  of  Section  2  shall  be  used  to  describe  each  test  as 
shown  in  Section  2. 1. 

2. 1  Test  (Identify) 

2.1.1  Data  Performance.  This  paragraph  shall  compare  the  I/O  per¬ 
formance  of  the  test  with  the  I/O  capabilities  as  described  in  the  Staff 
Manual  and  the  Acceptance  Test  Plan  when  applicable. 

2.1.2  Parameter  Performance.  This  paragraph  shall  compare  the 
parameter  performance  of  the  test  with  the  parameter  performance  de¬ 
scribed  in  the  Staff  Manual  and  Operations  Manual  and  the  Acceptance  Test 
Plan  when  applicable. 

3.  SYSTEM  FUNCTION  ANALYSIS 

A  decimal  subdivision  of  Section  3  shall  be  used  to  describe  each  system 
function  as  shown  in  Section  3.1. 

3.1  System  Function  (Identify) 

3.1.1  Function  Performance.  This  paragraph  shall  describe  the  functional 
capability  as  it  has  been  demonstrated  in  one  or  more  system  tests.  It 
shall  also  assess  the  manner  in  which  the  test  environment  may  be  differ¬ 
ent  from  the  operational  environment  and  its  affect  on  the  functional  capa¬ 
bility. 
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3. 1.  2  Performance  Limits.  This  paragraph  shall  describethe  range  of 
data  and  parameter  values  tested.  It  shall  also  identify  any  functional 
deficiencies,  limitations,  or  constraints  inherent  in  the  system  detected 
during  the  testing  process. 

4.  CONCLUSIONS  AND  RECOMMENDATIONS 

4. 1  Demonstrated  Capability.  This  paragraph  shall  provide  a  general 
statement  on  the  capability  of  the  system  as  demonstrated  by  the  test, 
against  the  performance  requirements  contained  in  the  system  Preliminary 
Function  Description.  An  individual  discussion  of  conformance  with 
specific  requirements  may  be  included  on  complex  systems. 

4.2  System  Deficiencies.  As  required  by  the  results  of  the  testing,  an 
individual  statement  will  be  provided  for  each  deficiency  detected  in  system 
operations,  as  measured  against  the  Acceptance  Test  Plan.  Accompanying 
each  deficiency  will  be  a  discussion  of  the  impact  on  system  performance, 
if  the  deficiency  is  retained,  and  the  impact  on  the  system  design,  if  the 
deficiency  is  corrected,  along  with  assignment  of  organizational  respon¬ 
sibility  for  the  correction. 

4.3  System  Refinements.  An  itemization  of  improvements  which  can  be 
realized  in  system  design  or  operation,  as  determined  during  the  test 
period,  willbe  given.  Accompanying  each  improvement  will  be  a  discussion 
of  the  added  capability  it  provides  the  system  and  the  impact  involved  on 
the  system  design. 
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1.  PURPOSE 

To  establish  a  glossary  of  systems  terminology  for  use  in  the  programming 
environment  of  NAVCOSSACT. 

2.  GENERAL  TERMINOLOGY 

Terminology  generally  used  in  the  programming  field  is  defined  in  several 
government  and  industry  publications,  including  the  following: 

Automatic  Data  Processing  Glossa 


Executing  Office  of  the  President, 

Bureau  of  the  Budget,  December  1962 

American  Standard  Vocabulary  of  Information  Processing 
(proposed)  - 

American  Standards  Association 

3.  SPECIALIZED  TERMINOLOGY 

3. 1  Terms  and  Abbreviations.  A  list  of  organization  identifiers,  opera¬ 
tional  terms,  item  descriptives  and  common  abbreviations  applicable  to  the 
preparation  of  common  system  documentation  is  contained  in  the 

NAVCOSSACT  Dictionary  of  Terms  and  Abbreviations, 

25  March  1964 


An  abbreviation  may  be  used  in  place  of  the  parent  terms  for  brevity,  pro¬ 
vided  the  term  is  fully  spelled  when  first  used,  followed  by  its  abbreviation 
in  parentheses. 

3.2  Glossary.  A  list  of  definitions  of  specialized  NAVCOSSACT  termin¬ 
ology  is  contained  in  Appendix  A.  _ _ _ 
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APPENDIX  A 

SPECIALIZED  TERMINOLOGY 

TERMINOLOGY  ORGANIZATION 

The  terminology  included  in  this  Appendix  is  organized  by  key  word  groups. 
Each  term  is  identified  by  one  and  only  one  key  word.  All  terms  with 
corpmon  key  word  are  grouped  together  in  alphabetical  order.  Thus, 
entry  appears  only  once  in  the  Appendix  and  multiple  listings  of  a  single 
entry  are  avoided. 

TERMINOLOGY  GROUPS 

To  expedite  the  search  process  under  the  single  entry  arrangement,  all 
terms  contained  in  the  Appendix  are  listed  under  their  respective  groups 
in  Table  A-l. 

CONFIGURATION 

Hardware  configuration.  The  layout  or  disposition  of  units  of  equipment, 
interconnected  or  not,  that  are  associated  with  an  ADP  facility;  e.g. ,  a 
central  message  or  data  processor  unit,  its  array  of  peripherals  (tape  units, 
line  units,  printers,  etc.)  and  EAM  units  (keypunch,  reproducer,  etc.). 


Organization  configuration.  The  physical  and  functional  structure  of  the 
ADP  user's  facilities  and  personnel  and  particularly  those  units  within  this 
structure  that  interact  with  the  ADP  facility  as  sources  of  input  data  and/or 
recipients  of  output  information. 
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Positional  configuration.  The  pattern  or  arrangement  of  the  positions 
required  to  be  manned  by  personnel  during  operation  and/or  maintenance 
of  the  ADP  system;  e.g. ,  console  operator,  EAM  supervisor,  staff  moni¬ 
tors  of  displays. 

Software  configuration.  The  composition  of  the  aggregate  program  system 
associated  with  an  electronic  data  or  message  processor.  In  addition  to 
the  operational  programs  that  satisfy  the  functional  requirements  of  an 
application(s)  there  may  be  included  control,  (supervisory),  support  (in-out; 
data  retrieval)  and  conversion  (assembler;  compiler)  programs. 

DATA 

Display  data.  Information  output  by  real  time  system  for  immediate 
evaluation. 

Data  message.  Grouping  of  related  data  elements  to  form  a  single  data 
set  for  convenience  in  transmission  and  processing. 

Parametric  data.  Data  values  incorporated  into  program  design  used  to 
enable  and/or  control  the  program  operation. 

Priority  data.  Data  identified  to  the  system  by  tag,  type  or  value  limits 
for  special  handling. 

Protected  data.  Data  stored  in  system  locations  accessible  for  change 
only  by  special  external  manipulations  of  hardware  and/or  software  ele- 
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Safe  data.  System  operational  data  periodically  read  out  of  its  dynamic 
storage  location  (core,  drum,  disk)  onto  a  static  storage  medium  (tape) 
as  a  contingency  against  data  loss  due  to  catastrophic  system  failure. 


Secure  data.  Classified  data  manipulated  by  system  with  explicit,  automa¬ 
tic  safeguards  for  its  transmission  and  output  only  to  designated  authority, 
usually  on  clearance  level  basis. 


Sensitive  data.  Data  (usually  classified)  with  additional  safeguards  for 
transmission  and  output  to  designated  authority  only  on  an  explicit  need-to- 
know  basis. 

Simulated  data.  Fictitious  values  of  data  inserted  into  system,  in  lieu  of 
actual  (usually  classified  values)  as  a  convenience  during  test  or  exercise 
of  the  system, 

ENVIRONMENT 


Hardware  (equipment)  environment.  The  assembly  of  equipments  operating 
as  a  system. 

Operational  environment.  The  complex  of  personnel,  practices  and  pro¬ 
cedures  which  exists  as  an  organization  for  the  fulfillment  of  a  mission(s). 


Organizational  environment.  The  hierarchy  of  personnel  and  their  associ¬ 
ated  responsibilities  which  exist  in  a  given  operational  situation. 
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Physical  (site)  environment.  The  assembly  of  equipment  operating  as  a 
system,,  including  those  aspects  of  the  installation  which  influence  or 
constrain  operation  of  the  system. 

REQUIREMENT 

A  statement  in  a  procurement  situation  of  that  which  is  to  be  provided  to 
satisfy  the  procurement.  It  may  be  applied  at  any  level  of  the  procure¬ 
ment  breakdown;  i.  e. ,  operational  (user  oriented),  system  (designer 
oriented),  subsystem,  program,  performance  (evaluation  oriented). 

SYSTEM 

System  Continuity.  Ability  of  system  to  maintain  normal  operation  or  a 
stated  degree  cf  operation  under  failure  conditions. 


System  effectiveness.  A  measure  of  system  performance  usually  as  a 
function  cf  stated  values  of  the  system  parameters.  Different  values  of 
effectiveness  will  normally  be  associated  with  different  values  or  sets  of 
values  cf  the  parameters. 
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System  flexibility.  Provision  within  a  system  to  modify  or  expand  the 
range  or  mode  of  operation  in  a  manner  compatible  with  the  basic  design. 


System  impact.  The  effect  on  a  system  of  proposed  or  actual  changes. 

The  effect  may  be  measured  in  terms  of  performance,  schedules  or  cost 
factors. 

System  interface.  The  technical  factors  associated  with  defining  the  man¬ 
ner  in  which  a  system  relates  to  another|totally  independent  system. 

System  maintainability.  The  capabilities  and  characteristics  of  a  system 
that  support  the  objective  of  continuous  availability  to  the  user.  This 
capability  is  represented  by  the  aggregate  of  maintainability  (preventive; 
remedial)  considerations  present  in  the  system's  design,  fabrication, 
installation,  operation,  and  personnel,  and  logistics  support. 

System  parameter.  A  quantity  representing  the  performance  of  a  system 
in  a  particular  area  or  consideration  (e.  g. ,  display  response  time).  A 
parameter  is  a  variable  constant  in  that  its  value  can  be  within  a  range  of 
values,  but  for  a  given  design,  configuration,  and  environment  (e.g.  , 
traffic  load)  of  the  system  it  is  fixed. 

System  redundancy.  The  considerations  in  a  system’s  design  and  config¬ 
uration  that  provide  parallel  or  duplicate  on-line  facilities  (e.g. ,  terminals; 
lines)  and/or  functions  (e.g. ,  components;  circuits;  equipments)  to  support 
continuity  of  system  operation. 
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System  reliability.  The  ability  of  a  system  to  operate  in  the  manner  in¬ 
tended  whenever  required  by  its  user.  A  continuously  available  system 
would  be  completely  reliable  (no  failures  limiting  or  discontinuing  opera¬ 
tion). 

TIME 

Real  time.  Ideally,  the  operation  of  a  system  in  which  input  events, 
conditions  or  perturbances  are  processed  and  output  immediately  as  dis-  j 

play  information  or  correction  signals  to  a  control  unit.  ) 

\ 

I 

i 

Response  time.  The  period  or  duration  of  time  to  obtain  a  desired  output 
from  a  system  (or  a  component)  measured  from  the  point  in  time  at  which 
the  system  (or  the  component)  is  stimulated  or  triggered  to  initiate  the 
output.  Total  response  time  can  exceed  system  response  time  when  inpu* 
and  output  preparation  are  required  of  operating  personnel. 

Throughput  time.  The  time  required  for  a  system  to  produce  a  desired 
output  measured  from  the  time  of  input  initiation.  This  time  will  be  a 
function  of  the  task  (type  of  input,  processing  and  output)  given  the  system 
and  the  operating  speed  of  the  central  processor  and  particularly  its 
electromechanical  peripherals  (e.g. ,  card  reader;  printer  or  card  punch), 


NAVCOSSACT 

STANDARDS 


SUBJECT 


PROGRAMMING 

TERMINOLOGY 


NUMBER 

50-05 


PAGE  OF 

8  8 


TABLE  A-l 

i- 

TERMINOLOGY  GROUPS 


Hardware 

Organization 

Positional 

Software 


Data 


Display 

Message 

Parametric 

Priority 

Protected 

Safe 

Secure 

Sensitive 

Simulated 


Environment 


Hardware 
Operational 
Organizational 
Physical  (site) 


System 


Continuity 

Effectiveness 

Flexibility 

Impact 

Interface 

Maintainability 

Parameter 

Redundancy 

Reliability 


Time 


Real 

Response 

Throughput 


SUBJECT 

PROGRAMMING!  •  *  * 

SYMBOLOGY 

1.  PURPOSE 

To  establish  a  list  of  symbols  and  their  meanings  for  genera!  reference  in 
the  preparation  of  programming  documentation  linework. 

2.  SYMBOL  TYPES 

Symbols  are  used  on  a  chart  to  represent  the  functions  of  an  information 
processing  system.  These  functions  are:  input/output,  processing,  flow 
direction,  and  annotation. 


A  basic  symbol  is  established  for  each  function  and  is  always  used  to  repre¬ 
sent  that  function.  Specialized  symbols  are  established  which  may  be  used 
in  place  of  a  basic  symbol  to  give  additional  information.  The  size  of  each 
symbol  may  vary  but  the  dimensional  ratio  of  each  symbol  shall  be  main¬ 
tained. 

Refer  to  Appendix  A  for  individual  symbols  and  their  meanings. 

3.  SYMBOL  USAGE 

3. 1  Symbol  Orientation.  The  orientation  of  each  symbol  on  a  flowchart 
should  be  the  same  as  shown  in  Appendix  Ar 

3.2  Symbol  Size.  The  size  of  each  symbol  may  vary,  but  the  dimensional 
ratio  of  each  symbol  shall  be  maintained  as  specified  in  Section  2. 

3.3  Flow  Direction.  Flow  direction  is  represented  by  lines  drawn  between 
symbols. 
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a.  Normal  direction  flow  is  from  left  to  right  or  top  to  bottom 
b  When  the  flow  direction  is  not  left  to  right  or  top  to  bottom,  open 
arrowheads  shall  be  placed  on  reverse  direction  flowlines, 
c.  When  increased  clarity  is  desired,  open  arrowheads  can  be  placed 
on  normal  direction  flowlines. 

d  When  flowlines  are  broken  due  to  page  limitation,  connector  symbols 
shall  be  used  to  indicate  the  break, 
e.  When  flow  is  bidirectional,  it  can  be  shown  by  either  single  or 
double  lines;  but  open  arrowheads  shall  be  used  to  indicate  both 
normal  direction  flow  and  reverse  direction  flow. 

4.  SYMBOL  ANNOTATION 

The  value  of  chart  symbols  may  be  increased  by  annotation  of  the  symbols 
with  pertinent  descriptions  and/or  numerical  values.  The  conventions  which 
apply  are  shown  in  Appendix  B 
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APPENDIX  A 
CHART  SYMBOLS 


The  symbols  which  follow  are  used  to  represent  processing  operations  on 
charts.  The  size  of  the  symbols  may  vary  depending  upon  chart  layout  size 
and  spacing,  but  the  dimensional  ratio  of  width  to  height  (W:H)  must  be 
maintained  to  the  values  given. 


Symbol 


W:H  =  1:2/3 


Meaning 

Input/Output.  The  making  available  of 
information  for  processing  (input),  or 
the  recording  of  processed  information 
(output)  without  a  connotation  of  media 
used. 


Processing.  The  process  of  executing 
a  defined  operation  or  group  of  opera¬ 
tions  resulting  in  a  change  in  value, 
form,  or  location  of  information,  or  in 
determining  which  of  several  flow 
directions  are  to  be  followed. 


W:H  =  1:2/3 
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MM 

Symbol 


Meaning 


Left,  to  right  Top  to  bottom 


Right  to  left  Bottom  to  top 


Flow  Direction.  Flow  direction  is 
represented  by  lines  drawn  between 
symbols.  Normal  direction  flow  is 
from  left  to  right  or  top  to  bottom. 

When  the  flow  direction  is  not  left  to 
right  or  top  to  bottom,  open  arrowheads 
shall  be  placed  on  reverse  direction 
flowlines.  When  increased  clarity  is 
desired,  open  arrowheads  can  be  placed 
on  normal  direction  flowlines .  For 
broken  lines  due  to  page  limitation, 
connector  symbols  shall  be  used  to 
indicate  the  break.  When  flow  is  bi¬ 
directional,  it  can  be  shown  by  either 
single  or  double  lines:  but  open 
arrowheads  shall  be  used  to  indicate 
both  normal  direction  flow  and  reverse 
direction  flow. 


Annotation.  The  addition  of  descriptive 
comments  or  explanatory  notes  as  clar¬ 
ification.  The  broken  line  may  be 
drawn  either  on  the  left  as  shown  or  on 
the  right.  It  is  connected  to  the  flow¬ 
line  at  a  point  where  the  annotation  is 
meaningful  by  extending  the  broken  line 
in  whatever  fashion  is  appropriate. 


Punched  Card.  I/O  function  in  which 
the  medium  is  punched  cards,  including 
mark  sense  cards,  partial  cards,  stub 
cards,  etc. 


W:H  1:1/2 
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Symbol 


Meaning 


Magnetic  Tape.  I/O  function  in  which 
the  medium  is  magnetic  tape 


Punched  Tape.  I/O  Junction  in  which 
the  medium  is  punched  tape. 


W:H  =  1:2/3 


W:H  =  1:1/2 


Document.  I/O  function  in  which  the 
medium  is  a  document. 


Manual  Input.  I/O  function  in  which  the 
information  is  entered  manually  at  the 
time  of  processing,  by  means  of  on-line 
keyboards,  switch  settings,  push  buttons, 
card  readers,  etc. 


Display.  I/O  function  in  which  the  in¬ 
formation  is  displayed  for  human  use  *t 
the  time  of  processing,  by  means  of  on¬ 
line  indicators,  video  devices,  console 
•printers,  plotters,  etc. 
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Symbol 


Meaning 

Communication  Link.  I/O  function  in 
which  information  is  transmitted  auto¬ 
matically  from  one  location  to  another. 
The  symbol  is  always  drawn  with  super¬ 
imposed  arrowheads  to  denote  the 
direction  of  data  flow. 


W:H  1:2/3 


On-line  Storage.  I/O  function  utilizing 
auxiliary  mass  storage  of  information 
that  can  be  accessed  on-line;  e.  g. , 
magnetic  drums,  magnetic  disks,  mag¬ 
netic  tape  strips,  automatic  magnetic 
card  systems,  or  automatic  microfilm 
chip  or  strip  systems. 


W  H  -  1:1 


Off-line  Storage.  Any  off-line  storage 
of  information,  regardless  of  the  medi¬ 
um  on  which  the  information  is  record¬ 
ed. 


Decision.  Operation  that  determines 
which  of  a  number  of  alternate  paths 
is  to  be  followed. 


Predefined  Process.  A  named  process 
consisting  of  one  or  more  operations  or 
program  steps  that  are  specified  else¬ 
where;  e.g. ,  subroutine  or  logical  unit. 
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Symbol 


W:H  =  1:2/3 


i - ^ — 

W:H  =  1:1 


Meaning 


Manual  Operation.  Any 'off- line  pro 
geared  to  the  speed  of  a  human  being. 


Auxiliary  Operation.  Anoff-lfpe  opera- 
tion  performed  on  equipment  not  under 
direct  control  of  the  central  processing 
unit. 


o 

W:H  *  i:l 


Connector.  A  junction  in  a  line  of  flow. 

A  set  of  two  connectors  is  used  to  repre¬ 
sent  a  continued  flow  direction  when  the 
flow  is  broken  by  the  physical  limita¬ 
tions  of  the  flowchart.  A  set  of  two  or 
more  connectors  is  ued  to  represent  the 
junction  of  several  flowlines  with  one 
flowline,  or  the  junction  of  one  flowline 
with  one  of  several  alternate  flowlines. 


CZD 

W:H  =  1:3/8 


Terminal.  A  point  in  a  system  or 
communication  network  at  which  infor¬ 
mation  can  enter  or  leave;  e.g. ,  start, 
stop,  halt,  dela>  or  interrupt. 


/ - \ 


W:H  =  1:2/3 


Preparation.  Action  or  task  preceding 
or  following  the  processing  of  data  on 
EAM  or  EDP  equipment. 
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Symbol 


M 


W  H -  2  - 1/2:1 


WH-  1.2-1  2 


Meaning 

Magnetic  Drum.  A  right  circular 
cylinder  with  a  magnetized  surface  on 
which  data  can  be  stored  by  selective 
magnetization  of  portions  of  the  curved 
surface. 


Magnetic  Disk.  Aflat  circular  plate  or 
coaxial  assembly  of  same,  each  having 
a  magnetic  surface  on  which  data  can 
be  stored  by  selective  magnetization  of 
portions  of  the  flat  surface. 


W  H  -  l:  1*1/2 


W  H  -=  11 


Magnetic  Core.  A  configuration  of 
magnetic  material  (e.  g. ,  ferrite  cores) 
placed  in  a  spatial  relationship  to 
current  carrying  conductors.  Data  can 
be  stored  by  selective  magnetization  of 
the  magnetic  material.  j 


W  H  -  1.2/3 


Deck  of  Cards.  A  collection  of  punched 
cards  comprising  one  or  more  files  and 
associated  control  cards. 


WH  -  11/2 


File  of  Cards.  A  collection  of  related 
records  (punched  on  cards)  treated  as 
a  unit. 
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Meaning 


W:H  ■  1:1 


Merge.  The  combining  of  two  or  more 
sets  of  items  into  one,  usually  in  a 
specified  sequence. 


Extract.  The  formation  of  a  set  of 
items  selected  from  items  contained 
in  one  or  more  sets. 


W:H  =  1:2/3 


Sort.  The  arrangement  of  items  in  an 
ordered  sequence  according  to  speci¬ 
fied  rules. 


Collate.  The  comparison  and  merging 
of  two  or  more  similarly  ordered  sets 
of  items  into  one  ordered  set. 


Parallel  Mode.  The  simultaneous  trans¬ 
fer  or  processing  of  the  individual  ele¬ 
ments  (e.  g. ,  bits)  of  a  whole  (e.  g. , 
word). 
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Symbol  Meaning 

_  Crossing.  The  traversing  of  two  or 

more  chart  lines  which  does  not  result 
in  a  junction  or  common  union. 


Junction.  The  intersection  of  two  or 
more  chart  lines  at  a  common  union 
point,  terminal  or  node. 
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APPENDIX  B 

CHART  SYMBOL  ANNOTATION 


The  information  content  of  chart  symbols  (Appendix  A)  may  be  enhanced  by 
the  addition  or  annotation  of  additional  data  within  the  symbol  itself  .  The 
more  common  items  of  data  annotated  onto  the  most  frequently  encountered 
symbols  are  located  within  the  symbol  as  follows: 

Symbol  Meaning 

Processing. 

EQ  ~  Equipment  designation 
PI  =  Program  identification 
OP  sr  Description  of  operation 


EQ 


PI 


OP 


/  FD 

_ _ EL 

EY-. 


Punched  Card  Data. 

FD  =  File  description  name 
FI »  File  identification 
EV  =  Estimated  card  volume 


Document. 

RT  *  Report  title 
RI  *  Report  identification 
EV  =  Estimated  volume  in  lines  per 
report 
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Meaning 


12 


Magnetic  Tape. 

j 

FD  =  File  description  name 
FI  =  File  identification 
RL  =  Record  len^h 
EV  =  Estimated  volume 


Paper  Tape. 

FD  =  File  description  name 
EV  =  Estimated  volume  of  records 
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1  PURPOSE 

To  establish  a  set  of  flow  chart  types  to  be  used  and  referenced  in  the 
preparation  of  programming  system  documentation. 

2  CHART  TYPE  VARIATIONS 

This  standard  provides  for  the  preparation  of  a  number  of  chart  types  to 
fulfill  the  need  for  variations  in  the  emphasis  and  detail  required  in  flow 
charting  at  'he  various  levels  of  programming  documentation.  Associated 
with  each  chart  type  is  a  unique  type  name  for  convenient  and  unambiguous 
reference  to  the  type  in  program  systems  documentation. 

3.  CHART  TYPE 

3  1  System  Organization  Chart 

a  Purpose.  Provide  an  over-all  view  of  the  system  configuration  for 
the  orientation  of  general  management,  staff  and  operating  per¬ 
sonnel  requiring  a  basic  understanding  of  the  system, 
b.  Content.  Block  diagram  representation  of  identified  functional 
areas/activities  related  to  the  ADP  facility  with  interconnecting 
data -information  flow  lines  between  applicable  blocks.  See 
Figure  1  for  simplified  example. 

3  2  System  Information  Flow  Chart 


Purpose.  Provide  a  comprehensive  presentation  of  the  flow  of 
data -information  within  the  over-all  system  for  the  benefit  of 
management,  staff,  and  operating  personnel.  The  objective  is  to 
she  w  the  trace  of  input  data  from  initial  generation  through  the 
system  to  final  output  recipient(s)- 
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b  Content  Block  and  symbolic  representations  of  input  data,  o  .,  :  )  ] 
tion.  and  cutput  information  irv  the  various  functional  areas  of  tv-c 
'  rganization  with  interconnecting  lines  denoting  forward  and  fe 
back  flows  c f  data  and  information.  See  Figure  2  for  simplified 
example  {Pictorial  representations  of  equipments,  e.g. ,  tele¬ 
typewriters,  tape-punches,  keypunches,  etc.,  may  be  included 
for  additional  clarification  and  understanding  of  the  flow  and  hand¬ 
ling  of  system  data  information.)  ( 


i 


The  chart  is  primarily  for  the  use  of  ADP  operators  and  program¬ 
ming  pers<  nnel  .  All  blocks  and  symbols  should  be  fully  labeled 
and  identified  in  regard  to  unit  ID,  run  or  operation  number,  data 
types  etc. 


3  3  Physical  Configuration  Chart 

a  Purp.  se  Present  physical  arrangement  of  system  to  support 
descriptir  n  of  system  operation  in  user  documentation, 
b.  C<  ntent  Simplified  layout  of  system  equipments  as  installed  at 
site{s)  sh<  wing  individual  equipment  outlines  and  their  relative 
positn  ns  See  Figure  3  for  simplified  example. 

3.4  Functional  Configuration  Chart 


a . 


Purp<  se  Present  sysiem  equipment  in  block  diagram  form  with 
interci  nnections  to  support  description  of  system  operation  in 
system  documentation. 
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b  Cor.tfn*.  Block  diagram  of  system  equipments,  grouped  by  function 
with  indication  cf  basic  data  flow.  See  Figure  4  for  example. 

3  5  Integrated  ADP  Flow  Chart 

a  Purpose.  Present  all  significant  aspects  of  data  flow  for  use  as  a 
means  of  communication  of  system  design  between  user  and  system 
*r.aiyst .  and  to  provide  basis  for  development  of  detailed  system 
design. 


Note.  For  complex  systems  an  Integrated  Flow  Chart  is  prepared 
for  each  maior  sequence  or  cycle  and  related  by  a  single  system 
chart. 

b  Content  A  complete  data  path  including  data  operations  and  inter- 
re;  *t  jcnsh.ps  throughout  system,  depicted  with  ADP  symbols.  See 
Figure  5  for  simplified  example. 

3  6  In/Out  Flow  Chart 


a.  Purpose.  Provides  the  system  operator  with  the  basic  sequence 
for  the  use  of  the  program  system  and  input  materials  to  produce 
an  output. 

b  Content  The  sequence  of  events  in  ADP  symbols  which  display 
the  maiiipilat'or.  of  input  and  intermediate  output  materials  related 
to  the  appropriate  system  processing  operation.  See  Figure  6  for 
example 
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3. 7  System  Logic  Chart 

a.  Purpose.  Provide  a  means  of  communication  of  detail  program 
operation  between  system  analyst  and  programmer. 

b.  Content.  The  sequence  of  processing  events  in  ADP  symbology 
to  be  performed  by  the  computer  as  prepared  for  each  program  in 
the  program  system.  See  Figure  7  for  example. 

3.  8  Program  Logic  Chart 

a.  Purpose.  Provide  a  definition  of  the  organization  of  the  logic  of 

each  program  in  the  program  system  for  design,  debug  and  test 
purposes.  •'*> 

b.  Content.  The  sequence  of  logic  processes  for  a  program  described 
in  compiler  level  language.  See  Figure  8  for  example. 

3.  9  Coding  Logic  Chart 

a.  Purpose.  Provide  a  definition  of  the.  coding  used  for  a  program. 
Normally  prepared  only  when  a  compiler  is  not  used. 

b.  Content.  A  step-by-step  presentation  of  the  coding  instructions  as 
they  will  appear  in  the  finished  program.  §ee  Figure  9  for  example. 

4.  CHART  TYPE  APPLICATIONS 

The  information  depicted  by  the  various  chart  types  is  applicable  to  a  wide 
variety  of  documentation  needs.  Selection  of  a  particular  type  will  be 
determined  by  the  technical  depth  and  interests  of  the  intended  reader. 

Table  1  provides  a  guide  for  use  of  individual  chart  types  in  programming 
system  documentation. 
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